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ABSTRACT 

Carnegie Mellon University has ctKwen to standardtee Its new administrative system 

ettorts on reiationsi database and SQL The INGRES reiaUonal database mmagement softwwe Is 

currently In use on several development profsds. One a dmin l slrallve computing lypHcaMon, the 

University InfonnaMon Sysism (UI8), uses relailonal database to dbMM^ 

empioyeedata. The UlSaenm as a good lest project for examining how rslaioncridatitese 

technology has affected administrative compuHrg. The flexJbWy and the porteMiKy of the product 

were extremely benefldailn our environment The aasy to use 4QL tools allowed us to produce 

prototype? faster and to quIcWy make changes to applications. The benefits to the users have been 

most apparem In the hiproved access to data that cunently exists wNh the UlS. 

Special oonslooratlons are associated with moving to relational database technology. Usere who want 
to obtain Its maximum t)enefK need to spend time in learning the stmcture of their data within the 
database, the INGRES query tods, and SQL AJminlstrallve Systems also must offsr a higher level of 
support for the new group of people now using the database and develop expertise in the effective 
management of database appHcsiions. 



INTRODUCTION 



Carnegie Mellon University an undergraduate and graduate InetNution located in Pittstnirgh, 
Pennsylvania Founded in 1 905, the former Carnegie institute of Technology now enroiis 6,900 
students and employs approximately 700 faculty and 2,600 staff. 

The computing enviromnem at Camegle Mellon can easily be descrl^ Students use a 

variety of personal computers, wor te taHons and some mabiframes to do their coursework and 
research. In the administrative computing environment , word processing and office data processing 
functions take place primarly on persoriii computers, partk^^ models, which 

are often Unked together through local area nelwoito to share resources Nke printers and file servers. 
A VAX cluster, (presently con^Ming of a 6330, 6230 anU three ll/TSffs ), a Sequent Symmetry, a 
Sequent Balance, and severed other wortotadon-dass machines currently support the central 
administrative computing at Camegle Melon. The Administrative Systems (A.S.) department senses 
the central computing needs of ttie university. 

The stated direction of a dmln te lra ll ve computing at Carnegie Mellon encompasses the relational 
database/SQL (Structured Query Language) starnlard combined wNh hardware and operating system 
independence. TheiNGRES database management software (a product of the 'NOreS Corporation, 
Alameda, CA) was seto^ for use as a basis for aR development pro|ects and runs In many operating 
system environments, kidudbig VMS, UNIX, VM and DOS. The operating system and hardware 
independence wH iMow us to take advantage of new opportunities presented by the ever-expanding 
technology base by giving us the freedom to be able to easily move applications from one 
environment to another. 

it is both useful and in te restlr ig now lo look at the impact of our decision to standardize our 
devetopment efforts on rsi aH onal databaso. Several rekAond applcatkms have been in use at 
Carnegie MeNon since approximately 1984. These Include systems Wee inventory Control, Work Order 
Managennent and TelecornmunicalkKis Manageme^ Recently, a new iNQRES-liased hluman 
Re3ouroe Management System saw Its first nu^or release. The Student Informatkm System, whteh 
manages student records, admisetons and student accounts receivable, was put into productk>n a few 
shortweeksago. Many other devetopment protects are in progress. We have chosen to examine 
one system in partkxjiar, the University Information System (UiS). This system, whkii was begun as a 
prc^ In late 1985, is one of the larger, more wkleiy-used adminlstraUve retatkxiai database 
applteattons at Camegle Mellon. 

THE UNIVERSITY INFORMATION SYSTEM 

The UiS is an INGRES appllcatkm that provMes the user wNh retrieve ac 
emptoyeedata I'he need for such an inquiry system was evMerit at Camegle Melk>nse 
ago, when It was apparent tl at the central systems, written in COBOL and housed on Digital 
Equipment Corporation's (DEC) DEC-20's, were not serving the needs of the user community. The 
central systsrns altowed access to data in a very Ihnltsd fwl^ 

problems wi!h an over-k>aded machine. W^to plans were behg fornied to replace these systerns, 
partlcularl) the Student f^ecords and Payrr^M/Personnel sysleme, the new verskm of the systems 
were too far away and wouM not solve immediate problems sunrounding access to data. Thoughsome 
data were avalMble to users in the form ot starxtard screens and printed reports, the need existed for 
access to data In a riHxe ad^ioc fashkm. Thai Is, users wanted to be Able t 
rosters, teadhing toad reports and sfltoy surveys as they were needed or to examine data in their flies 
quickly and easily. 

Because the technotogy to altow users this kind of access to data was avalaM 
database software, and because the need for access to information on campus was so strong, the 
dedston was made lO provkle the campus community with an Interim solutton to Its problem. The 
University informatton System was buiK to give users a way to get the 



while the new aystems were being designed arKl developed Formatted screens and standard 

reports, similar to those avaliable in Itie old systern, tHJt more flexible and robu^ 

UiS, along with the avaNabity of SQL for usere to write and njn their own ad-hoc queries. 

Previous versions of the UlS received their data on a nightly basis, via FTP from the source 
the old TOPS systems. Mow, since the new INQRES-based Student i n fom w Boii System and Human 
Resource htfbnnailon System have been released, data contained In the UlS continue to be extracted 
lirom the new systerns and shipped on a daily basis to a Sequem Symmetry lurmlng the ^ 
operating system, whsre they are loaded into 6.1 INGRES database. The decision to continue to 
maintain an Inquky^iniy' database after the release of the new systorns was made for several 
reasons. First, lAving the second database would reduce the load on the primwydaliybase. This 
would be helpfiJ during the first months of the release of the new systerns, vvhite bugs vvere being 
worlted out and the system was momtorsd. Second, since the fded to the UlS was e*eady in place 
and the applcatlons were in use, H would not require much effort to simply continue the data trnnsfw^ 
This ateo aitowed the developmerit of the 'inquhy portions of the new systems to be delayed until a 
later date. 

The UlS data rettoct what is contained in the central systems, and are availabto to users for query 
acoessonly. Usere are not pennitted to change any date in the UlS. Any errors found must be 
conected at the source, which b the central system. 

As mentioned earlier, the UlS data are made up of student arxJ employee InfonTWtton. Sepcrate 
applications exist for access to these data Each application oonsiste of standadized screens, 
queries, reports. A mabi menu atows the user to choose which subset of the iV>piicatton.ie wishes to 
njn. The menu, which is written in Calows the user to choose to nm the screens, queries or reports, 
print copies of the documentation, check when the data were last updated or enter the SQL query 
facMty. 

Ssassn- AH ttie UlS screen applications consist of an entry screen and data screens. The entry 
screen gives the user the abilty to search for a student or ernpioyee by none through the 'name 
search-option. A Ist of aH names that mateh the criteria typed by the user wM be dteplayed in a special 
screen if the name search option is setoded. The user can then select the student or emptoyee he 
needs and cal one of the data screens. 

Each data screen in the UlS contains data about one entity: a student or a course or an employee. For 

example, in the studem screens application, the 'roster* screen shows aR studente in a oertirin course 
and section for a given semester. 

The user can move eesRy from screen to screen by typing the new screen code over the cunrent 
screen code. In the case of a 'roster' screen, this action calls u different screen for the same couree 
without retumbig to the main menu. ThesamemethodappHes to changing the entity « the semester 
being retrieved - if the user wants to see a new student on a shJdent-based 8cre*m Hke the 'grade' 
saeen, he simply types the id number of the new student over the Id number of the current student if 
a new semester is desired, the desired semester is typed over the old semester. Any combination of 
sa-aen code, semester or entity can be changed in order to retrieve new data. 

QjuSm- Commonly-used queries were written and bistaiiod in the UlS in a menu fonratt. Nospedai 
sldns, such as knowledge of SQL, are required to njntt^ query option of ttie application. Users 
simply setod ttie desired query and enter a few simptoparametere. When a query is run, the results 
are written to ttte scrsen as wei as to a fito, which can be manipulated further by ttie usere. 

Bansaa. The report generatton option of ttie UlS applications gives users ttie opportunity to produce 
results for larger, complex queries that are needed on hard-copy, and that are not of a time-crltteal 
natute. Again, the desired report is selected from a menu of avaHabtoreporte and parameters are 
entered prior to execution. In order to conttol system load during ttw day and avoid large disk space 



allocations for aach user that would be required by INGRES to run the reports, the report requests are 
submitted to a batch queue wtiere they are executed when system utMzalion Is low. 

Asi ^floceas . One of the driving loroesbeNnd the Implementation of the UlSvi^ 

users to have better access to data The lllS screens, queries and reports were duplications of and 

enhancements to the features available on the old central systems. The ad-hoc query fadHty avaHabto 

with INGRES was the key to providino the broader access that rnany users require 

to retrieve data rtot aveAable througli standard reports or on the inquiry screens. The ad-hoc query 

option is avaRaUe from the main menu and requires a knowledge of SQI^ the data manlpulatton 

language used by INGRES. IJsers mcy form their own stalsrnents to select data from the database. 

perform aggregaltons or do simple fUe extracts. 

ThftHfltii jhB UlS database consists of approxknatety 350 megabytes of data representing 

lnfomiaik)n firom 1975 through the presem, contained In over Several types of 

tables exist bi the UlS. Theyare: rnaki data tables, kKlex tables, translallon or utllllytiM^ 

owned tiMes. Tliemo*) data tables contakitfie data shipped to the IJIS from the central syM 

example the Student Schedule Table, which contains a record for every student for every course 

taken dufkig a semester, consists of abnost one rnMon rows 30 bytes wk^ Index tables are created 

when the database ad rnWstra lo rdelkies primary and secondary keys tor d^ 

Important for eflteient execution of queries. Translatton tsriMss hoM codes and thek meanings, and are 

used consistently by the scrsens, queitos and reports to provMe the EngHsh translatton for a given 

code. Other utINty tables kKdude the tables used tor trackto^ 

system. 

Protectton . AR data to the IJiS 4tfe consktored to be sensitive data (grades, salailes), SO ^ 

is needed. INGRES provktos a pennNfCKilfy that dtowsdsta to be protect 

based on vahies to fieMs. Abo, the days of the week and tkne of day ttie database is avalaUe to users 

ovi abo be wecHled. Once the populatton Is defined tor a user with specNte permits on data tdbles, 

hisworMofvlewislhnitedtothatpopulalton. Whether he is nmntog the screens, a query, a report or 

executing his own SQL statement, the data avaRabte to hkn are ehrays that same base populatton . 

User Community . TTie user community of the IJIS applcalton spans a broad segm 
Melton community . >^toei)re;)Ments, department heads and administrative and dertoal einptoyees 
from both the academte and admtolstratlve sktes of the university make up the approximately 200 
peopto who have access to the detabase. 

RELATIONAL TECHNOLOGY 

As our current envkonment has grown fron: the previous generation of tradiVonel, COBOL-based 
systems to appRcattons using relaitonal database management software and based on the rslattonai 
model, we ftod It usetol to took at what advancing to ths next generatton of computtog has brought to 
the university. The eftorttovoived to maktogthto move is cllen very clear but sonie^ 
ssw to advance wtiat the benefits or problems wM be. 

Tho advantages of using rslattonai databases for our admtolstrative computtog needs are many. We 
can examtoe what we see as advantages of relattonal datal>ase from the perspective of the users as 
well as from the perspecHve of Admtolstraflve Systems. 

Advantages to User 

Acoaaa to Data. For those users who have no need or desire to go beyond the use of simptotoqutry 
scrsens, any differences between an application written ustog a relational database manager and an 
appHcation wrttlen to COBOL may go unnoticed. However, those users who to the past were welt 
aware of the stmcture and Iknitatlons of thek COBOL appNosrt^ 
power they have with dkect SQL-based access to the data. 
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The retaMonal model is easy for novices to underst^ The database Is structured In the wiw that one 
wouWrwIuraihrj^^ 

entity. As Date, a vveR knovm ai4ho% on rslalionai database rnmi^^ -a 
table consists of a row of colunmheedhgstogelhe'vvlth zero or nwie rows of data val^ Foraolven 
table, (a) the oolunm heedktg row specHles one or more columns; (b) each data row contirins exa^ 
one value for each of the columns specified m the odumn heading row." The relationship between 
tabim In the database is expressed by con)mon,l(ey fields. The concspt of "data independence" 
Irwutales the users, as wel as the programmers, from having to understM^ 
poWere or underlying data access mothods In order (or a user to mompuiate data No knowledge of 
complex data structures, pointers or underlying data access mefhoda Is required. 

Even the novice user can use the INGRES todc, such as QBF (Queiy by Fornw) or RBF (Report by 
Fomw) to do simple, fonns-besedinqulrlos of the data WNhabaslounderstmdlngoflhe tiMe 
structure and SQL. the novice user can perform simple select statements to retrieve data 

Fw the more sophWIcaled user, the rslallonal database and Its assoc^ 

VVim some training In order to become famMar with SCM. and lem the daliiMse stnjctu^ 

««h an appNcallon, users find ttiemselves wNh the abWy to do complex me^^ 

hoc manner. Many of our users have created their own tables to use In coiAmcten with the 

applcatlon tables. These "private" tablee can be Joined easly wHh the up-to-date data the 

databases. Users have also found it unneosesaiy to stors redundant data In their own peraonal 

computer appRcadons, since the csntral data they need are now easlyaocessMe. Itlsalsomuch 

easiw now to move any needed data to personal computer applications for use whh other 

rMckages. due to the easy^o-use command to extract data from the INQRES databases and the 

available access to data transfer programs ■» FTP or KERMir. 

Data can be viewed In ways prsvlou8lyimpoesl)le without complex programming, Itsgelyduetothe 
dalalndependenoe In relalional databases, or the 

detaNs of the way the data are stored and accessed. For example, using the old systsms to produce a 
class roster required that a complex COBOL progrsm be mn th« would produce a roster fbr every 
dassoffersd that term. The output We was then divided and distributed to the upiopriale 
departments. Changes to this procedure required the users to request progr a mming and testing by 
AdmMsliallve Systems and ofteii wait weeks for the resuRs. Mow, not orily on a user do a simple 
Toln" of a tables, he can ImH his rsquest to rosters for a s^ 

all m one SOL "selecr statement Views can also be defined to nwritellfe easier for mend-iner. A 
viewr Is a way to alow a user to loolt at one or more tdbles as one entity, provMhM logical data 
Independence. When defining the view, the links between the tables m estiMshed, md the loins 
are executed eveiy time the view Is selected. 

The users' ablity to do ad-hoc selections of data on their cwn has In many cases reduced their 
dependenqr on central computing staff. Administrative users on campus need not waH the several 
weeks It oouM have taken In the past to have a rsport they requested written, tested, debugged and 
njn by the oentral computing staff, who address requests h) order of priority. They can write their own 
request, submit It and have their rssuRs almost Immediately. The OfHoe of University Planning in 
partka^ has made extensive use of the query and report generation facWties aveiable 1^ 
University InfomMrtkm System to do the large anwunt of reporting fw 

responsible. Indivklual departments on carnpus are also producing their own class rosters, reports 
and academki audit rsoords viHh the UI8 database. 

PartictoaMon In rxwign Pnj^fj Perfiaps some Of the most unk|ue advantages of the lelattonal 
database for the users cononn user parttelpaMon In the system design process. In more tradltk)nal 
^tem devek)pment environments, user requlrsments were translated Into an mfonnatkm system by 
the programmers. Often, by the time the system was completed, user requirements woukJ change 
Now, because of the easy, rapid prototyping that can be done by the system devetopers (see next 
sectkjn), users get to see the system In eartler stages h the devek)pment ilia cyde and consequently 
offer suggestkNis or critkilsmseariler. Users do not have to antteipate all their needed reports or 
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(unclbns during the system dwignsta^ It is retaMvely easy to write a new report a add anew sc^ 
onoe the initial system design is In plaoe. Adding such obfecls does not require any changes to the 
undertyingda'.abase and can tie done easily usin^ next section.) 



Advantagee to Admlnlatratlve Computing 

Administrative Systems has indeed seen an increase In productivity and general system quality and 

flexlk)iiity since the relaiional dalalMse and its 4QL fools h^ 

development. The relallond model and Its way of representing data In tables ha^ 

for developers, in the database design process, the rslationalrm)dei forces the developer 

users to view data In sets wd examine the relationship between those sets. This helps to breakdown 

the process of designing large, Integrated databases into sma^ 

communication between user and developer. 

Productivity. The INGRES software comes with its own tools to buM applcatlo^ 

increase bottt the level of productivity and the overall effectiveness of the applications programmers In 

Administrative Systems. The logic portion of the applcatlon Is specified In ABF ( AppSoaMon by 

Forms), the appiraHonbuMer. T!* Is separate from scrsenconstnicllon, which Is done through 

VH^ED, INGRES' forrns bulkier, often referrsd to as a 'scrse^ This separation dtows for 

easier and ftMer changes to be made to an applcatlon, skK)e the two 

independently. 

By usfng VIFRED It is simple to spediy and later change field location, field vaNdaHon, screen titles and 
field dsplay attributes, such as on-screen highHghHng, default values or color. Once a screen has 
been created, any feature can be easily atfwted. The INGRES software handles al the screen 1^, so 
no complex program Is needed. lnanr)atHirofafewfnlnules,aslmplescreencanbeoon 
a user can be entering or se le c t i ng data from the database. 

Two simple interfaces to the database are avaiable that QBF 
or GKieiy 1^ Forms, Is a screen Interface to the database that "Allows ^ 
deletedala Default QBF fonns can be cusloinbEed with VIFRED to order to add enwchecl^ 
customize the scrsen. No code Is required to use QBF to an C4)plcatlon. The same kind of function, K 
written to COBOL^wouM require hundreds or thousands Ines of code. RBF, or Report by Fonns, 
provides simple formatting and retrieval capabllitles through a defauN report on a stogto tabto. The 
detauN report formats can be changed or enhanced easily. Nooodhgisli^volvedtocrealtogareport 
wKhRBF. 

A more comptox reporting tool, called Report Writer, aRows much more compfcated reports to be 
written than does RBF, sW with no rsal code required. Report Writer aRows the resuNs of a query to 
be formatted and aggregated using ernbedded oornniands. TTie Report Writer commands are slmpto 
to learn and are combined wito the SQL 'seled" statement to inake up the ecript AReport Writer 
script for a very complex report rnay be only one to one and one-haW pages to lengto Reports 
spedlled with RBF can be written out to a Report Writer scrips where th^ can ^ 
complicated report is required. 

The key to the appRcaltonbuiMtog process Is INGRES' ABF or Applte^^ This tool aRows 

the developer to tfe together the pieces of the appRcatton written using VIFRED, QBF, Report Writer 
and 4GL (Fourth Generalton Language) code. TTie 4GL that ABF uses, cuffed OSL, Is the tod used to 
specify most of the appRcatton togte. 

The abRNy to write most of the appRcatton control and togic to OSL code has In most cases reduced the 
necessity to write C or COBOL routlnee. Only In sNuattons where the procedure requ^ was too 
cornptox for OSL to efRdentiyhandto or where high perfonnance was so critical WM 
appRcatton converted to C and optiinlzed for inaxirmjm perfbrman^ 
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A simple appHcaiion can be prtxJuced using OSLa^ Duringthe 
appi^don deveioptnent process, this dbilily to vwy quicMy make a system prototype has been very 
vaiuabietodeveiopere. The deveioper can start vwlth an iW«<»«on "sheil" thrt 
screera and (unctions, and vvorkwrtlh the users to alter or enhance the Very HtHe worK Is 

rec^jhwdup-lrort for tWs process to take piace^ 

something the user does not ll(e or wants to change substantially. By using the 4GL application 
buNder, the prototype of the system Is the real basis for the final product. I.e., m most aases the 
prototype becomes the fined product. *^«uif» 

In general, we have experienced an increase in overaH development productivity since the relational 
database and 4QL tools have been used. The decrease in development time has given us the 
opportunHy to spend more time up-front on systems analysis issues, and has given us the abHHy to oet 
system prototypes In the hands of the users faster than ever before. 

SfifiUdbt. As mentioned earlier in this paper, the underlying pemitt fadmy handles aoc^ 

levels and is very flexUe. Admlnistralive Systems' programmers are not required to write dala access 

rouMnes for each applicallon. FadWIes for database auditing, checlq)olnting and JoumaHng have «teo 

elimlnaled the need for any prograrns to be wrmen to perfbmi these fUncttons hn^^ 
security. 

BbOMl- We have been pleased wllh the overall flexibility of the relalionaldatet>ases. Inaf^cases 
where they were needed, changes to the system were easy to make, even after the firial product 
release of the applteaikm was in place. Addbig a fleM to a table does not affect the scplkallions 
mplace. The applkalkm code wisti run, without change or re-con^)!^ This is atrue advmtMe 
o\w more ttadHtonal Nerarchteal or network databases, where 

the Stylyt Btographteal data table. Orfginalty designed to be semester-based, the teSewn^ 
many flekto that were staite from semester to semester. THededsksn was made to change the 
JSfSS® reflect university record keeping. wNch woukf reduce the table size from 

800.000 rows 10 40.000 rows. This change, whteh required changes to the data toadina proorams 
some screens, queries and raporte. and the database fomrwt took less thm one week to 
In a norvretettonai system, this wouW have involved a complete re-vifrte a^ 
the appicatran code. 

CaiStimc- in addllton to ftexibimy. portability of applkxrttons across dmaram hardwares 

WHh ihe ll>KaRES software we have been *bte to demonstrate that this is a laasonsWy sh«^ 
do. Asanexampto.theUISwasmovedfromllsof1gkialhomeonmlBM3083toaVAX8^in Iras 
th« one month. wHh moat of Ihe thne being spert on making any 0^ 
such aspalh names In references to flM^ 

thedalabaMandlnre-wrlllngtheappH^^ VVhena 
second port of the UlS vim done, the UlS (dalitese only) was moved from t^ 
Sequent Batanoe 8 machine ovemlghL The pieces of the code written h COBOL and DCL were re- 
written In Con the Batance. in order to make the appRcaHon as por^ Asate8t.wewere 
abto to move the enthe applkxrtkm from Dynix back to VIMS hi toss than a dey. 

Mahtgiwnw . Devetopment vwHh 4QL's have gready sbnpliltod aspects of system maintenance. 

Because ABF altows us to tte together many procedures and screens. If a change must be made to 
one part of the appNcaHon. the entire appikK^ need not be re-compned. Storing data in tabtes 

ralher than havtog It hard-coded in programs vMso altovvs users to charKje appNcatkins with no 
progranmner Interventton. » -^f- 

DteWhtmKJ Prtabaaft Tachnology. nnaHy, we see distributed database, in the fonn of INQRES/STAR 
being a tme asset to our admrnistrative computing efforts in the years to come. STAR now altows two ' 
or more databases to be opened simultaneously, whether they are on the same node or on different 
nodes. This feature is used frequently to administrative appHcaHons when connectivity to other 
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datdt>asMisrequii^.arKlalo^uf to^i^ A 
further benem of distrlbutod dalitese te^^ 

wt4chm Inked together via a conrv^^ Thedala canbe 

stored ai any number of nodes and users at any node can see any of the data without having to l^no w 
ortf>specNywhereitls. In tNs way, rnore data are available to rnore people, whRe at the sarneti^ 
possible to store each piece of data on the macMna where It is most of^ 
efficiency. 

OTHER CONSIDERATIONS 

Although the benefits of relational database are many. It Is also Irnportam ^ 
effects associated with moving to this technology and to also l<n)k a^ 

reladonai database effectively and efficiently. Many database vendors matce great claims about the 
rale at which your productivity will Increase, how simple tlie toob 

you wM have to do. You are cautioned to not be fooled by such claims. Although productivity does 
tend to Increase, nothing happens ovemlghtl 

For Users 

Along with the Improved access to their own data, users now have the responsibKty of learning how to 
effedively use the tools that are available to tt^ If they choose not to tal<e advantage of SOL or the 
other tools lll<e DBF or RBF, rnost 01 the advantages of the nrx»ve to re^ 
totheuser. We have found that support of Ihe^em by upper rnanagenMrt Is Irnpor^ 
leaning process and the general use of the ( tem. High-level support for the technology has had 
an effed on Its use at Carnegie Melon, perlicuMfly In thecal When users at the vice- 

presidential level used the UlS and saw the advantages that this s 
others on campijs who were also dMe to tal<a advantage of the newty 

It Is irnportant to users that they set aside time to attend classes to learn th^ 

andloiemSQL An In-deplh understanding of what data are contrtried In 

irrtportmt to the user who virtil be writing SQL stalernents to rst^^ Some time should be 

reserved each day for the user to spend h practice sessions In order to becorne tamr 

and SQL, the database and the operaing system. We have seen many users attend an SQL dass 

and then not pracHce what was covered In dass. When they need to do an ad-hoc query, they have 

forgotten what they had learned, and are unable to mato ful use of the system. 

Although users are required to know more than ever before about how their systems wortc and may 
find ihisleanilngtobeatinne-consurnlngprooesSrttlsirnportamtostresst^ 
Invested Initlaly in looming the database layout, the applet 

future. They wM have better access to their own data, wM not have to go through a "middle 
(adrnlnlstratlve ooinputing) In al cases to get data they need and wV b^ 
in a more efficient ftehlon. 

Remember that SQL is stir a programming language, and sometimes SQL and database concepts wilt 
be difficult for mend-user to master. One should be realistic In these oases, and encourage a user 
vvho is having dHflculty to master the fbnrartted screen 

later date, once comfortable with the screens. Insomecasee, eHherduetolacicof InWat^e, 
understandbig or abMty, some users never become comfortable enough with SQL to do their own ad- 
hocquerles. Many users wM be oomem with the "IIHn-the-form* variety of appi 

Although sorne dalm that end users are never going to use SQL [3], ou^ 
few 1<ey* users arise In each department or administrative area These individuals tend to become the 
resident expert tn SQL and are most often also the people In the department who have a good 
understanding of the data. These people have been able to sennas a consultant for others in their 
departmnt who are experimenting with SQL 
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For Admlnlttrttiv* Computing 



The acMWon of ratadonal database applk^rttora 
of fesponslbHWes for AdminlshaUve Systems. 

Imtataa- Training new users was a significant part of ttwsuooessfuldepl^^ 
database appMca H ons. Staff who befors were developere and users of the old appNcatlons needed to 
learn how to (»e the new tools avaMHe to them. As the user oommunKy grew, many people who 
previously dW not have access to any electronic data eSdo needed to be trsrined. Our experience with 
the Universiiy Infomwllon System showed us that Administrative Systerns needeJ to plan 
prasem training on the database layout. SQL and other INGRES tools, as wel as some operatic 
system concepts. Several sessions, spanning days or weeks are usualy required to give most users a 
basic, wortdnglqwwiedge of the appMcallon and the database inana^. A few days between training 
sessions was also found to be helpful. This time iapee gave users schtk time to practice v liat was 
discussed in the formal dass, and to rslum with questions in the fdowmg session. 

We also had to trabi our own staff. A few people in the dep a rtment were relational database 'experts* 
when our mafor development began, but a good part of our staff were ItamtradWonaiC^ 3rd 
generation programming language badtgrounds. Some training was done intemaHy by our own stafl, 
but we did send large groups to one-weei( training sessions given by the vendor, irt addMon. cerMn 
staff were sent to spedalzed vendor training in advanced pedormance or codlns. TMsiMoosts 
money, and you should plan for this In your prelect budgets. As we have added staff over the past few 
years, we continue to send them to the one week "INGRES for progremners" course, and wM provi^ 
Internal reviews of database concepts on a regular basis. 

SuBPQIl- in addHton to the up-frort training requirement, our department must plan for on-going 
support of these users. It is Important to have a staff member avalabie to take "emergency* cals from 
users who are having trouble with simple tasks like ranning the screen applk»tk)n, as wel a^ 
with more sophistkarted users who are atternpting to writo complex queries or Re|Mrt Wrtlw 
Unless help Is available, users wH sometimes gl>^ up on the applcaOon. 

AnfflWM IMIHW. We have talked some iribout the benefits of distributing the ad-hoc access to the data 
wIthSQL This method has Its drawbacks, in addltton to users having problems fonnulatkM their 
queries, there Is the danger that they may write and execute "bad* queries. Meet often, these are 
*dl8|oint*querief that do not property Join tables. The usual consequence of this adton Is that the 
database manager executes a Cartsslan product and the user's query mns out of dMk space md fails. 
On a fsw occastons, however, the databases have become Inoonsistsnt end consequently 
inaooessfcle to aluseraunti a 'restore* cornmand can be execulsd by the database admini s trator. 
(Aulomalto restoratton of the database, as wel as automatte delectton of queries generattog very tog^ 
resuitsare partof verston 6 of the INGRES software, but for user of verston 5 It is a manutf process.) 

in additton to the problem wNhdbjoInt queries, another unantkiipated problem has arisen. Userson 
oocaskm are found to be mnning large, complex queries in interactive mode that are cornpeting wim 
regular produclton for machine cycles on the oenlraltlme-shaiing systems. No good sohJtkm as to 
how to handte this problem has yet been detonnlned. Not aN users can afford to own their own worit 
staAon, where they oouM use their own machine rseourcee. Access to the dauyMne cm be Nmited to 
certc*) hours of the day, or users can be forced to execute al queries in belch mode at a tower priority. 
This second opttonwouMprohM users from running sirnple queries during the (tay. Rlghtnow,we 
are attertpting to educate the users who are writing the more sophistteated queries about how their 
wortt affects the rest of the users on the machtoes, and when and how they shouM do their worie A 
more permanent soiutton nnust be devised. 

Many sites have chosen to avoM the problem of users causing inconsistencies to the productton 
databases by provMtog them with an addHtonai inquiry database. Having a dupltoato database for 
Inquky puq[)oses also provMes an eddNfonai !evei of security (no changes can be rnade to the live' 
database) and helps Irnprove perforinaf)ce for the users of the on-line inquiry screens, who are not 



compe^fig against massive update, delrie or ackl transactions. This sohitloti requires tt^at the 
addttional dtek space be avaMble, that anotl>er database be maintained, and that the additional 
database be updated on a re^lcr bas«8. Although thb method Introd u ces the possibility of the two 
databases being *out of sync,' depending on the vdarillty of the dale In the source system and the 
resources avalabie, tNs r iary be a good mettiod to use when production databases are Involved. 

P a ttenmanoa . QetUng good performanoe from a database appBcalion Is an Important part of database 
management and should be given a high priortty. First an^i foremost good database design Is crttlcal 
to good performance. A large percentage of tt>e develrpment effort, prot>ab(y somewtiere around 
3S%, should be speiit In the design phsie. We have found that wfien enough tinne was spent on 
developing a good design, itie s^tom pertorrnanoe issues were 

Once the design Is in place and the applications written, If a database Is not property ^luned" the result 
wWbeaslowsystomtftglwibethesouroeofmanyoomplaln te ^ Database progr a mmers must be 
pro|)ei1y trslned In tiow to take advantage of the dslakMoe management system and to use It In 
con|uncilon with the operating system to KdfulestpotentW^ Sufficient time should be allotted during 
the system teeting phcM of any protect to tune the database and appl^^ 
p e rtbim a noe. The "luning" process Inoiudee property eetab^ 
indtoes, dtotributing the data across dbks and gathering stallstin 

In query execution. Fine tuning should be an ongoing mrt n t e nance procees. Careful management of 
al aspects of the database, indudtog Indexing, optki^atlon, locMng, datiA>ase Integrity and user 
pennlts Is crucial to the efflderit operMlon of the applca^ 



SUftlMARY AND FUTURES 

Since the Implementation of lha first rstaHonal daHtese application for adminis t ra t ive use at Ca^ legle 
Melon, a trend has e)dsted toward broader dtetributton of data and Innm inibrmaiion. 
The sla n d ard ba Bon of al admW s trallve computing on the rslatlonal model has brought with It many 
advantages, both to the user and to the dsia processing staff. Though sonw special training and 
expertise is required to prof>eriy maintain, administer and use theee systems, the benefits they bring 
are of critical importance to the operation of thb unlversNy. 

Futurs dirsctions for reiwional di^stabase in administrative computing see even nrK>re work being done 
In the area of tfie dtetributed database environment, througii INQRES/STAR, to provide our users with 
access to mariydMsrentdelabasee appearing to be a single system. We also see the GATEWAY 
products, which provide Inks to other databases (Mte DECs RDB) or lies, (9uch as RMS files), to be 
useful to Ink exMingnonHrelaMonalsysternswNhl^^ dabbases. 

FlniMy,we hope to soon be taMng grsaler advantage of the nature lan^ 

whkiiwM alow our end users to have tul access to their data by sirnply making their requests In simpto 

Er.glsh. We hope thai this approach wM provide users with greater flexMlty In th^ 

elmlnate the rsqufcement of l e o ming SOL to make the greatest use of the data in their systems. 
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ABSTRACT 

Even small shops can provide remote access to CD-ROM 
databases such as MEDLINE , £Bi£, AGRICOIA , and Books in 
S£in^* Despite having a limited technical support 
staff, we"ve done it in a DECNET environment* 

Many extremely useful databases are available on CD- 
ROM. At our medical college, researchers, physicians, 
and students clamored for CD-ROM hardware and software. 
This confronted the administration with numerous 
departmental requests for identical CD-ROM players, 
microcomputers, and database subscriptions. 

Rather than duplicating these systems, we connected a 
CD-ROM player to a device called a "V-Server" on our 
VAX system. It isn't magic, but if users* demands are 
great, funds are limited, and you use the DECNET 
communications protocol, it works. 

This presentation also reviews alternative CD-ROM 
networking solutions using a Novell network, MACs under 
TCP/IP, and remote multi-access CD-ROM without 
networking. 
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I. Brief Introduction to CD-ROM 
A* Hardware - how it works. 

CD-ROM (compact read-only disk) Is a new technology that Is 
breaking all previous barriers for storing ccmputc^r data. A 
small 5*-lnch disk typically holds up to 600 megabytes of 
data. This is the equivalent of nearly 1,500 magnetic 
floppy disks of information I CD-ROM stores more because the 
focal point" of a laser beam is much smaller than a typical 
"^magnetic" disk head, thus more information can be stored on 
each disk. This has allowed many companies to "compact" 
thousands of pages of Information on a single disk. 

In addition to being efficient, mass-production of CD-ROM 
disks is very economical. CD-ROM disks are not susceptible 
to magnetic fields and cannot be accidentally erased. 

B. Software - irtiat databases are available? 

New titles are being released every day. Typically, CD-ROM 
applications are based on LARGE database systems. To date, 
there are over 300 titles available. A sampling of 
databases (for education) include: 



MEDLINE -index to medical journal articles 
BOOKS IN PRINT 
BOOKS OUT OF PRINT 
ELECTRONIC ENCYCLOPEDIA 
WORLD ATLAS 

ERIC -index to educational research literature 
PSYCHLIT - index covering material of psychological 
relevance scanned from over 1300 journals from more than 50 
countries 

ABI-INFORM - a business database consist ir^g of abstracts '3ind 
indexing to business articles from over 80C business and 
management journals 

TOMES PLUS - information on industrial chemicals, hazardous 
materials, toxicity, and emergency responses. 
. . .and many, many more. 

(At this CAUSE session we're distributing copies of the CD- 
ROM Sourcedisk f a CD which contains CD-ROM product titles 
and vendors and also copies of the magazine CD-ROM Endusar . 
which introduces this useful technology.) 
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C. Cost - Hardware and databases 

CD-ROM drives (that attach \ a a PC) typically cost between 
§8C0 and $1400 depending oh the type of drive and 
configuration. CD-ROM disks (databases if you like) can 
cost as little as $89 or up to $4000. Many CD-ROM databases 
are purchased as a "subscription" for a yearly fee which 
usually includes monthly updates. [These costs do not 
include the microcomputer system . ] 

D. Why use CD-R(M? 

CD-ROM databases are popular b.^cause they prt .de a means to 
access almost limitless amounts of information in a small 
space. Depending on your facilities, you may already have 
most of the hardware needed to implement a CD-ROM database. 

The most important factor in considering a CD-ROM purchase 
is cost. If you need the information, AND if you can 
implement a CD-ROM system effectively in your institution, 
then you have cause to consider purchasing a CD-ROM system. 

Another factor when considering a CD-ROM purchase is ease of 
ufif • There is no atandar<^ in the ways software packages are 
written to access CD-ROM inf orma*:ion . Some packages are 
menu -driven and easy to use; other packages may provide more 
information, but are more cumbersome. MEDLINE alone is 
currently sold by more than a half-dozen vendors. Each of 
these systems is y^ry different from one another. If you 
get a chance to "demo" a system, do so. 

Speed ie also a factor. Although CD-ROM disks hold 
megabytes of information, CD-ROM drives are somewhat slow. 
Most users are not inhibited by this, as how much 
information is available usually outweighs how fast they get 



Nonetheless, there ate alternatives to CD-ROM systems, all 
of which should be considered first. 

E. Alternatives to CD-ROM systems 

The first alternative that should be considered is "outside 
access". Many vendors provide access to their databases for 
a license fee. In the past, we have used the "Grateful MED" 
dialup service that the National Library of Medicine (NIM) 
offers. All any use^ needs is a PC/terminal and a modem. 
The service ie convenient and is offered 24 hovirs a day. 

The cost for this particular service is approximately 
$23.00/hour for "prime-time" access (9am - 4pm) and 
$16.00/hour for "non-prime -time" access. Given the number 




of researchers at our college that utilize the system, this 
has proved to be too costly. However, given a different 
situation, this would be a cost effective way to access 
MEDLINE. 

Another alternative is using "in-house" systems that are NOT 
CD-ROM based, but normal "load-your-own*' systems onto 
computer disks. Typically, you purchase the software/data 
that runs on your existing computer system. This is an 
excellent solution if you can afford it. 



II. The problem: A description of our previous non-network 
setup 

A. Hardware configuration: the "standalone" model 

Our initial configuration is a "standalone" model. It 
consists of a PC/AT workstation with two internal CD*-ROM 
drives and a slave printer. This workstation is physically 
situated in our Medical Library and is exclusively dedicated 
to running MEDLINE (from Online Systems ^ . which consists of 
a total of eight (8) CD-ROM disks. 

Faculty and students use the MEDLINE system to search 
through literally millions of medical journals to finu 
information relevant to their research. Because of its 
popularity and effectiveness as a research tool, this 
workstation is in use almost all day during Mbrary hours. 

B. Problems and limitations 

The primary problem with this setup is that of the location 
of the workstation. Faculty and students must reserve a 
time slot to use the system and must physically go to the 
library to perform their data searches. Our medical complex 
is physically large, so for many researchers, this proves to 
be extremely inconvenient and/or impractical. 

Additionally, the workstation is only available when the 
library is open. Many of our faculty perform their research 
after midnight (or weekend evenings) when the library is 
closed, and thus they miss being able to use this powerful 
research tool at their convenience. 

Finally, because there are only two disk drives, users 
occasionally must "swap" disks:. This is an inconvenience 
and slows search time a bit. 
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C« Cost of adding users - unacceptable! 



The cost for a CD-ROM workstation (Including all software 
and licenses) can easily add up to between $5,000 and 
$8,000. We could attempt to solve the eUDove 
problems/ limitations by "duplicating" this setup across 
c€uaiipus In various locations, but the costs would add up very 
quickly, and not enough staff Is available to manage each 
separate workstation. Obviously, this was not the best way 
to expand our resources. 



III. The solution: A description of our "multi-access" setup 

A. The new hardware configuration - uses mostly existing 
hardware 

To solve the problem of purchasing costly redundant systems, 
and to overcome the fact that PC CD-ROM applications are not 
usually "networkable", the MIS department used what Is 
called a "V-Server", from Virtual Microavstems , Inc. The V- 
Server is a device that contains four (4) 286-based 
processing cells, and lets any VAX terminal (VT compatible) 
run PC-based applications. At the time, the V-Server was 
being used by staff who have terminals and who do occasional 
PC work, usually word processing or spreadsheets. When the 
need for additional MEDLINE access emerged, we realized that 
the V-server offered a way to Implement remote MEDLINE 
access . 

The V-Server connects to the VAX via a standard ETHERNET 
ceible, and uses the DECNET protocol to communicate with the 
VAX. Each of the 4 V-Server cells comes with an expansion 
slot, so It was easy to hook up a CD-ROM disk controller. 
PC "disks" are actually virtual disks stored on the VAX. 
The V-Server cells handle the processing, while the VAX 
handles terminal communication. 

[see figure l on page 10] 

The nicest benefit of this setup for us is that It uses 
mostly existing hardware: By connecting the CD-ROM disks to 
the V-Server, MEDLINE Instantly became available to all of 
our hardwired and dlalup users. 

The problems of physical location of the CD-ROM system have 
been eliminated, and the cost (approximately $10,000 for a 
4-cell V-^erver) were definitely reasonable. Note that we 
also use the V-Server for many other DOS applications in 
addition to the CD-ROM application, so the money Invested 
was well used. 
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B. Probleas and liBltatlons 

Although the V-Server Is "PC compatible", there are 
obviously differences. It took a lot of parameter 
"tweaking" to Install the CD-ROM software properly. We 
discovered that our MEDLINE uses quite a bit a memory, so we 
had to upgrade the CD*-ROM V-Server cell with expanded memory 
($1000) to work properly. 

The second problem Is that although the V-Server can be 
accessed by anyone [with a termlnal/pc] on our campus, only 
one person can access the CD-ROM system at a time. This Is 
because only one of the V-Server cells can access the CD-ROM 
disk. Until recently, this has been a minor inconvenience 
for our users. However, the CD-ROM system has become so 
popular that we are addressing the problem of simultaneous, 
multi-user access to CD-ROM now. 

Another problem with the V-Server is, as mentioned above, 
that it expects a VT-compatible terminal on the user end. 
The keyboard mapping thus becomes somewhat awkward (i.e., 
"F6" on a VT220 terminal to enter an "Fl" for the PC 
application) . This problem is further compounded by users 
who use PC's to dial into the system, who end up with a PC 
emulating a VT terminal emulating a PC. Virtual 
Mlcrosvstems (the V-Server vendor) is currently developing a 
terminal emulation package for PC users that will map all 
keys on a l-to*l basis to make it much easier to use. 

At this time, MACINTOSH users still have to put up with the 
odd keyboard mapping. Nonetheless, one physician MAC- 
enthusiast has contrived a way to use the V-Server MEDLINE 
from his MAC. Once we resolve IBM/PC problems, we will then 
work on the MAC next. 

€• Reaction of staff and students- enthusiastic! 

Most of our staff and students were familiar with the 
Library's CD-ROM MEDLINE system, but many did not use it for 
reasons described above. When they found out we were 
hooking up a similar system accessible from the VAX, the 
reaction was fantastic. We have now set up several users 
(over 50) who all remotely access the system. The amount of 
data on the CD-ROM disks, combined with an excellent 
software package, have helped researchers tremendously. 

Our department has received many calls and a several letters 
commending the system, and they all want more! 
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D. The next step - Using a NOVELL network in our setup 

As mentioned aJacve, a major limitation of our current system 
is that it can be only accessed by one user at a time. The 
solution? We might set up the CD-ROM system on some sort of 
PC-BA:3ED network, such as Mfixsli. However, at first glance, 
this seems too expensive, and also takes the VAX out of the 
picture as the communications front-end. 

Academic Computing Services at the University of North 
Carolina (Chapel Hill) has proposed an ingenious setup that 
uses both solutions, using a Novell network and the V- 
Server. This solution solves the above mentioned problems. 

The setup involves attaching multiple CD-ROM disks to a 
Novell file server. Each of the V-Server cells is then 
configured with a network card (in the expansion slot) and 
thus each V-Server cell becomes part of the CD-ROM network. 

[see figure 2 on page 10] 



This approach solves our current problems, and is cost 
effective. A complete network (with workstations) need not 
be purchased; only one workstation (the server) and up to 
four (4) network cards. The CD-ROM disks which are now 
attached directly to the V-Server would instead be attached 
to the network server. 

We have found four vendors of CD-ROM networking products - 
Artisoft;, inPf, Meridian Data. Tnc. . Online, inc.. and CBIS. 
Inc. Base systems range from $2,000 for a 5-user system to 
$15,000 for a 20-user system. 

IV. Other multi-user CD-ROM possibilities 

A. MACINTOSH-based disk server 

The solution (s) shown edsove all met our needs. We are ' 
running a DEC VAX with DECNET, and the V-Server happened to 
fit into this nicely. 

What about non-DECNET sites? In our research of various 
solutions, we have uncovered some alternatives for sites 
that may not be configured as ours. One answer involves the 
use of a MACINTOSH computer as an APPLESHARE file server. 

Stanford University recently evaluated a system called 
"Knowledge Finder" that uses a Macintosh SE computer working 
as an APPLESHARE file server over a PHONENET network. In 
turn, this APPLESHARE network is connected to the campus 
TCP/IP ethernet by using a Kinetics Fastpath gateway. 

7 
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Thus, users of Macintosh computers across the local PHONENET 
or other similarly-connected PHONENET networks can all 
access the CD-ROM server. Their evaluation was successful, 
and they have implemented the product campus-wide. 

Like us, they too implemented a solution that fit into their 
existing configuration, namely the TCP/IP network. 

B. Modification of the Vserver 

Another alternative that could be investigated is to have 
the technical staff at Virtual Microsystems modify the V- 
Server so that the CD-ROM drive is accessible from ALL of 
the V-Server ''cells", and not just the one cell that the 
disk controller is attached to. 

This gives us a ''non-network'' multi-user system, and is 
somewhat cheaper than the Novell system. 

This would be a satisfactory solution, but it is slightly 
limiting. First, we would be required to "invest" a few 
thousand dollars of funding to have Virtual implement this 
solution, and it might be quite some time before the 
finished product is ready. 

In addition, this limits our use of the CD-ROM system to the 
V-Server^ and it gives us little flexibility to move to 
another configuration in the future. 

Multi-user access WITHODT the VAX 

Obviously, not everyone reading this paper has a VAX. 
Fortunately, there are many solutions. The latest solution 
to this problem has only recently been addressed by network 
vendors. Both Novell and Gandalf Technologies have recently 
introduced network systems that do not use any front-end 
whatsoever, nor do they use workstations. Instead, these 
network systems work with many PC's or ASCII terminals, 
connected through a serial line. The result is much like a 
V-Server, in that you can easily provide remote access to 
networked systems, specifically CD-ROM. 

The costs for these systems range from $10,000 to $20,000 
(CD-ROM hardware/ software not included) . This type of 
system does NOT make use of your existing systems, except 
for your modems and/ or communication lines. However, this 
type of system does free you from dependance on any 
particular mainframe system and/or network, and it can offer 
extremely flexible communications alternatives. 
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Conclusion 



A. livaluate your needs 

Should you buy a CD-ROM system? Only your users can teli 
you. Find out the needs of your user community. Next, 
compare those needs with your knowledge of what*s available 
in the marketplace. Subscribe to many of the free CD-ROM 
journals available to get the latest information. 

The Medical College of Wisconsin found an increasing need 
for the MEDLINE database, since the initial library 
workstation was installed, our need for access to this type 
of system hna grown exponentially. For us, alternate 
methods of access (e.g., licensed external services or 
building in-house disk systems on the mainframe) were too 
cosfly to be accepteODle. 



B. Evaluate your ''systems 

Take a look at your existing hardware. Does it lend itself 
to hooking up some type of PC-BASED system? There are many 
options . 

DEC VAX systems (like ours) can hook up to many types of 
computers easily, we happened to have a third party product 
(V-Server) that made access to PC-BASED applications easy. 
There are many ways to enable mvlti-user access to CD-ROM 
systems. Use your own hardware if you can, as cost 
effectiveness is always important. 

C. Choose the solution 

Finally, make the choice appropriate for your institution. 
We were able to implement a solution that was extremely cost 
effective with a minimal initial investment. Because we 
were doing something "new" with our particular MEDLINE CD- 
ROM software system, the College received a 1-year license 
grant to make sure the system was functioning properly. 

Check with your CD-ROM product vendor to see what type of 
evaluation periods are available. Although CD-ROM productr> 
provide a great way to distribute information, licensing can 
sometimes be costly, and the wrong choice can mean an 
unsatisfactory system. 
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Figure I. Existing V-Server/CD ROM setup 
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Figure 2. Possible future layout 
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U-VIEW: STUDENT ACCESS TO INFORMATION USING ATM'S 



John J. Springfield 
Boston College 
Chestnut Hill 
Massachusetts 



U-VIEW allows students to display and print their Boston 
College records at automated teller machines (ATM's) 
located throughout the campus. By inserting a magnetic 
striped ID card and typing in a personal identification 
number (PIN) , students are allowed access to their 
courses, grades, student loans, student accounts, 
financial aid, addresses, and other personal information. 

ATM'S are "natural" to the student 'because they can be 
located in convenient areas and are available after 
normCil office hours. In addition, the U-VIEW ATM's have 
builtin 80-column printers. U-VIBW has improved life 
for administrators by eliminating many inquiries. 
Records are more accurate because students are reporting 
errors. The ATM security features include the ability to 
capture obsolete and stolen cards. ATM's are rugged 
enough to be located in unattended areas. Future uses 
include the ability to drop and add courses, view urgent 
messages, and update records. 



500 



An Old Idea I A New Idea 

The idea of distributing computer access to user departments is 
not new* However, if we expand the term "user" to include the 
student (the true "end-user"), we are soon confronted with a 
whole set of issues that must be confronted. How do we 
guarantee security? What hours should access be allowed? What 
kind of devices should be used? Should the devices be located 
in hallways, dorms, or kiosks? Should full-page printouts be 
available? Should the new service complemenc or replace 
existing departmental access? 

After pondering this idea you soon reach the conclusion that 
you need a device that can read encoded ID cards, is intuitive 
to use, has a built-in printer, and is rugged enough to resist 
abuse. In short, you need an ATM (Automated Teller Machine) 
that has an 80-column printer instead of a cash dispenser. 



First Attempt - Terminals with Mag Strijpe Readers 

Borrowing an idea from David Ridenour of Indiana State 
University ("Allowing Students Read-Access To Their Own 
Computer Records", CAUSE/EFFECT , March 1988), we decided 
to set up terminals with attached mag stripe readers in three 
high-traffic locations: outside the registar's office, inside 
the library, and next to the cashier windows. Since students 
already had encoded ID cards, we di^ not have to set up new 
administrative procedures. By late summer of 1988 students 
were using "U-VIEW" at these single purpose terminals to 
access their courses, grades, loans, accounts, financial aid, 
addresses, and other personal information. U~VIEW was easily 
used by swiping an ID card through thd card reader and 
supplying a birth date. It was an instant hit with both 
students and administrators. 

However, there were problems with this approach. Specifically: 

. Some students inadvertently locked the keyboards by 
pressing cursor and other keys. A stauOard refrain 
from the registrar's office was "Hit the reset keyl" 
Clearly, the standard keyboard was too complicated. 
All we needed was a simple numeric keypad and a few 
function keys. 

It became apparent that most students wanted and 
needed a printout. Long lines were being created 
because students were copying information from tho 
screen to paper. 

Because the terminals and card readers sometimes 
confused students, there had to be a staff person 
in a nearby office to help them. It was obvious 
that these devices were not self-sufficient enough 
to be left totally unattended. 
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Terminals had to be secured at night because 
were not designed to resist abuse or theft. 



. Although the system could detect anyone with an old 
or stolen ID card, we had no way to automatically 
retain the card. 



Experimenting vlth an ATM 

By the fall uf 1988 it was clear that we needed a device that 
looked and acted like the standard ATM that was commonly used 
by banks. The main difference Is that we needed a built-in 
printer instead of a cash dispenser. students were used to 
using bank ATM's on and off campus, if we could find an ATM 
with a 80-column printer we were sure we could solve our 
problems. But did such a device exist? 

After contacting NCR and Diebold, we discovered that Diebold 
had a model 1060 "Everywhere Teller Machine", it was exactly 
what we needed 1 It had a 20 by 40 column display screen, a 
numeric keypad, four function keys, and an 80-column printer. 
But could we communicate with it via VTAM and CICS7 It 
supported SNVSDLC protocol, hut the vendor had not heard of 
anyone rigging it up In the manner we proposed. After we 
secured a loaner ATM and manuals from Diebold, we were on our 
own. 

When we received the ATM in December or 1988, our first and 
biggest task was to see if we could talk to it. Rod Peak, 
Computer Center Director and seasoned system programmer, dove 
into the manuals. without Rod I would have hit a wall. Rod 
described the ATM to our system as a control unit with a 
logically attached terminal. To CICS it was set up as a 3600 
device, within a month Rod had CICS talking to the ATM. After 
that I retrofitted our existing U-VIEW application to work on 
the Diebold ATM. By February 1989 we went live and became the 
first college to use an ATM to dispense student information. 



U-VIEW on an ATM 

The ATM is left powered up at all times except for periodic 
maintenance. when it is first powered up, a CiCS transaction 
sends a series of "states" and "screens" to the ATM. These 
states and screens allow the ATM to have limited functions even 
when CICS is subsequently brought down, without accessing CICS 
the ATM can handle menu navigation, timeouts, and Incorrectly 
Inserted cards. But once a student requests data, the ATM 
sends a message to a CICS transaction and waits for a response. 
Response time is fast when displaying data. Printing data 
takes longer because of the relatively slow printer. All 
access is recorded on a log file on the mainframe. 
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The first screen appears as follows: 



BOSTON COLLEGE 
U-VIEW 



PLEASE INSERT 
YOU BC ZD CARD 



A 
II 



1 


2 


3 


4 


5 


6 


7 


8 


9 


0 


CANCEL 



0 
0 
0 
0 



(Four 
Function 
Keys) 



The card is read by the ATM and verified that it is an active 
BC student ID card. If it has been report'^d tolen, it is kept 
by the ATM and reported to the security administrator. It is 
important to note that all cards are kept by the machine until 
the student is finished. At the end of a session, the card is 
partially released to allow the student to retrieve it. If the 
student walks away, the card is reta<ned by the ATM. 



The next screen asks for the student's PIN number: 



PLEASE ENTER 




YOUR PIN NUMBER 




xxxxx 









The PIN is verified. If incorrect, the student . ^ ' ..owed two 
more tries. The card is rejected after the third incorrect 
attempt. If the student contnues to reinsert the card and enter 
an incorrect PIN, the ca^d in retained after 9 tries security 
administrator is notified. 
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Once the student is allowed entry to U-VIEW, the main menu 
screen appears s 



PLEASE HAKE 






A SELECTION 






PERSONAL INFORMATION > 




0 


ACADEMIC INFORMATION > 




0 


FINANCIAL INFORMATION 




0 






0 



After this menu are various sub-menus and screens showing 
the desired information. All navigation is done by pressing 
one of four function keys. Each non-menu screen alxows the 
student to press a functic ^ key to print the data on the 
built-in printer. Since the screen is only 40 characters wide, 
the printout usually has more detailed information that the 
screen. 



Here is an example of a present semester course screen: 



COURSE NAME 


SCHEDULE 


LOCATION 


GENERAL CHEMISTRY I 


M W F 8 


102 


CUS 


GENERAL BIOLOGY I 


T TH 10 


1C4 


DEV 


CALCUrUS I 


M W F 1 


207 


HIG 


INTRO TO LITERATURE 


T TH 11 


001 


FUL 


PRESS TO 








PRESS TO 


CONTINUE - 







Note that the print and continue functions are always 

positioned on the last two lines on the non-menu screens. For 

security reasons screens and printouts never have student ID'S 
or names on them. 
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By selecting various options at each menu, students are allowed 
to view and print the following information about themselves. 

• Home, local, and parent addresses 
. Vehicle parking permits 

• Academic status and rank 

• Last, present, and next semester courses 

• Advisor and registration appointment time 

• Student account 

• Financial aid 

• Student loans 



H uman Factors 

Even though jumping the technological hurdles watt personally 
excitx.ig, it is the human factors that have and continue to be 
chellenging. Students respond well to the simple keyboard and 
familiarity of an ATM. We tried to mimic the human/machine 
interaction of a bank ATM wherever possible. However, there 
are still some human factor problems that do not offer an easy 
solution. 

Our first problem centered around the printing of information. 
Should we automatically dispense each printout after each 
selection, or should we wait until the student ends the 
session? Even though it wastes paper, we found that people 
want a printout immediately after they press the print function 
key. So we form feed the paper out of the machine as soon as 
possible. 

Another consideration is the length of time that is allowed to 
view a screen or answer a question. If we do not allow 
sufficient time to read all the information (say 25 seconds), 
we frustrate the user. However if a long response time is 
allowed, users may walk off without taking their cards 1 

Our current dilemma involves the changing of the menu structure 
based upon the time of year. During drop/add period virtual 
all students want to see their courses. After the end of the 
semester they want to see their grades. Instead of going 
through two menus to reach the selection, we could 
automatically put the most frequent selection on top based upon 
the time of year. However this may confuse the "frequent user" 
student who is used to seeing things in the same order. 
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Shared Administration of U-VIFW 

To make U-VIEW work successfully it was imperative that key 
departments be involved in overseeing it. We were fortunate to 
already have most of the pieces in place before the project 
began. 

The ID card if issued by the campus police. If a card is 
stolen of lost the campus police investigate and reissue cards. 
Cards that are retained by the ATM's are turned over to the 
police on a daily oasis. 

HIS handles the programming, the computer center manages and 
maintains the ATM's, and network services maintains tn« 
connections and checks daily for worn-out ribbons and lack of 
paper. 

The security administrator monitors an online log of U-VIEW 
access. Students are notified if there has been suspicious use 
of their cards. Statistics are kept on daily and monthly 
usage. 

The registrar and other offices are very helpful in suggesting 
improvements to present features as well the need for new 
options. 



Acceptance of the ATM 

From the beginning the ATM was a success. Everybody seemed to 
say, "Gee, why didn't we do this years ago?'', students now 
have "one-stop shopping". Administrators can be ^reed from 
answering simple inquiries and use their time o*^ the more 
involved student questions and problems. 

The fall of 1989 showed the following usage of the ATM: 

MONTH NUMBER OF STUDENTS 

September 5285 
October 2304 
November 3828 



On slow weekdays about 100 students use the machines. Busy 
days will show over 500 students. 

It should be noted that we expect this count to increase as we 
add more capabilities. We are purposely keeping the functions 
static until we have more ATM's. We do not want to simply move 
the lines from an office to the lines to the ATM's. 
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Future Enhancements 

Currently we have restricted scudents to Inquiry mode only. The 
next step is to allow updates, viewing and sending messages r 
and requesting printouts requiring batch processing. Some of 
this may require an ATM with an alpha keyboard, more function 
keysr or voice and video. ATM use could also be opened up to 
faculty, staff, and alumni. 

Here are a few ideas for future use of the ATM: 
Drop/Add 

Allow students to drop/add courses that require no 
departmental permission. 

Student Elections 

Use the ATM like a voting machine. Insure that 
students only vote once. Voter turnout would 
increase. Results would be known instantly after 
polls are closed. 

Updating Local Addresses and Phones 
Students can update their own addresses by choosing 
from a list of dorms or neighboring streets. A free 
form address would require an alpha keypad. 

Messaging 

Urgent messages from home, campus police, faculty, 
adminstrators, or other students could be displayed 
automatically on the first menu screen. The sending 
of messages would require an alpha keypad. 

Faculty and Staff Usage 

Allow faculty and staff to view their address and 
phone, payroll deductions, etc. Currently anyone 
having access to a CICS terminal can view their 
records. However some staff may not have access to 
a terminal. 

Alumni Usage 

Alumni could view their records, request theatre or 
sports tickets, or request information on current 
donation projects. 



Conclusion 

The ATM has proven itself to be an effective way to distribute 
information to students, free administrators of tedious tasks, 
and generally improve the quality of life at the university. 
It's greatest strengths over standard terminals are the 
security features, convenience, ease of use, resistance to 
abuse, hours, and ability to print full-page information. 
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IMPLEMENTING A CENTRALIZED DIRECTOR Y AT LSU 

Emilio A. Icaza and Ouida H. Carroll 

Administrative Information Systems 
Louisiana State University 
Baton Rouge, Louisiana 



ABSTRACT 

After twelve years of developing online data base systems, LSU 
achieved a major goal of integrating administrative data processing 
systems by creating a centralized repository called the Directory. 
The Directory stores name and address information about an 
individual, and serves not only as an entry point to such systems 
as Payroll, Personnel, Student Records, and Traffic, but also as 
an indicator of an individual's relationship with the University. 
Because the Directory collects information from administrative 
offices spanning different areas of responsibility, user 
coordination was a critical requirement during the development of 
the system. Both users and analysts were challenged during the 
deiign to evaluate the needs of the University as a whole, in 
addition to the needs of the individual offices. Topics of the 
presentation include design requirements, special features, and 
problems encountered during design and implementation. 
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INTRODUCTION 

In the course of managing adir'nist native computing development 
strategies, the direct involvement of users is indispensable. 
However, users sometimes seem to focus on their immediate needs 
as opposed to the needs of the University. As a leader of a 
technology group charged with the responsibility to deliver 
solutions to the community, what do you do if multi-departmental 
priorities conflict? How do you consolidate the requirements of 
many departments into a unified "institutional requirement" and 
work toward its implementation without direct departmental 
sponsorship? 

in this presentation we will describe the steps that we at 
Louisiana State University took to design and implement a 
centralized. University-wide Directory system. We will describe 
the environment that lead to its development; we will explore the 
managerial as well as technical issues we faced; and we will give 
you enough insight into the rewards of doing this so that you will 
leave here ready to try it yourself. 



THE LSU ENVIRONMENT 

The University 

At the time this project was conceived, Louisiana State 
University, had a management structure as follows: 



Chancellor 



V. C. 

Academic 

Affairs 



V. C. 

Business 

Affairs 



V. C. 

Student 

Affairs 



V. C. 

Relations 

Develop. 



V. C. 

Admin. 

Services 



V. C. 
Research 



Our department. Administrative Information Systems (AIS), 
reported to the Vice-Chancellor for Administrative Services. For 
many years AIS had concentrated its efforts in developing 
applications that, while focused on the needs of the University as 
a whole, addressed mainly the needs of the individual sponsoring 
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departments. Because of this departmentai emphasis, a promise 
that we made in the late seventies, to develop data base systems 
that shared information, had not yet been fully realized. 

For example, offices under all six of the Vice-Chancellors, were 
managing directory information (name, address, and phone 
numbers) through the many systems already developed, but they 
were not all coordinated. Let's visit with some of them to 
experience the problems they were having. 



Public Relations 

Meet Libby Paxton. Libby works for the LSU Office of Public 
Relations. Public Relations reports to the Vice-Chancellor fo" 
Alumni Relations and Development. Libby is in charge oi 
Publications. She and her colleagues publish many of the 
University's publications like the catalogs, brochures, magazines, 
etc. One such publication is the LSU Phone Book. Like many 
other universities' directories, the LSU Phone Book includes 
information about students, employees, and the University 
organizational structure. 

Prior to the Directory system implementation, Libby obtained 
student name, address, and curriculum information from the 
Student Records data base. During the fall registration process, 
students were given an opportunity to correct their name and/or 
address through scannable forms. After registration, these 
forms were used to update the data base. Later, the information 
was extracted, converted from upper case to upper and lower 
case, and formatted for the typesetting system. While this 
approach gave the students a chance to request corrections, it 
was too early in the semester to reflect the many housing changes 
the students made as they settled down for the school year at the 
University. 

Employee information was kept in a file used exclusively for the 
Phone Bf>ok. Every year, Libby surveyed the LSU campus 
community to determine if there were changes in 
employee-department affiliation, name, address, and title. The 
file was then updated with the results of the survey, and after 
some validation, formatted for the publishing process. 

The University organizational structure and key managerial 
contacts for tiach department were maintained in files containing 
the typesetting markup language codes. To keep these files 
up-to-date, Libby sent copies of pertinent pages to each 
department for their review. However, because of the lag 
between the annual review and the publishing of the book, she 
had to "monitor the grape vine." For example, organizational 
changes, and management personnel appointments and promotions 
approved by the Board of Supervisors, LSU's management board, 
were incorporated into the files before publication. 
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The Public Relations environment suffered from some obvious 
problems. First, the student address information was rarely 
accurate and in order to improve its quality, the Phone Book was 
often delayed to allow for updates to the Student Records data 
base* The name and address data in this data base were kept in 
all upper case, while the Phone Book was published in 
upper/lower case. This meant that a considerable programming 
effort was required in creating the publishing files from the data 
base, seldom with optimal results* Second, Libby's employee 
information did not carry the social security number, as a result, 
it could not be used to update the personnel data base. This 
deprived the rest of the community from the benefits of Libby's 
efforts to obtain current information. 



Office of Telecommunications 

Meet Chip Dodson. Chip is in charge of the Office of 
Telecommunications and reports to the Vice-Chancellor for 
Administrative Services. Chip has a group dedicated to provide 
directory assistance about LSI! to the community. This group is 
supervised by Sandra Hodges. Sandra and her colleagues 
dispense phone and address information to callers. 

Prior to the implementation of the Directory system. Directory 
Assistance relied on several sources for the information they were 
asked to provide. The primary source of information was the 
Phone Book. Sandra kept a "master" for th4 office with hand- 
written corrections and additions. She updated the master with 
changes she got though their daily contacts with the community. 
Hand-written cards provided by the Personnel Office informed 
them about new employees and changes in job classification. 

In early 1987, Chip's predecessor came to us with the desire to 
do something about the Directory Assistance service. He wanted 
to explore new ways to obtain existing information on students 
and employees and improve the quality of the service. He was 
facing some turnover due to retirement and felt that the 
experience level of the operators would be difficult to replace. 



Office of The Treasurer 

Office of Parking Traffic and Transportation 

Meet Judy Williams. Judy works in the Treasurers office 
supervising billing and student fee collections. The Treasurer 
reports to the Vice-Chancellor for Business Affairs. Judy is 
talking to Gary Graham, who is the director of Parking, Traffic 
anii Transportation . Gary reports to the Vice-Chancellor for 
Administrative Services, and is in charge of monitoring parking 
areas, traffic flow, and alternative means of transportation on 
campus. 
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Prior to the Directory system implementation, these two offices 
shared names and addresses which were separate from the student 
and employee records. Students gave changes to a Student 
Records clerk who updated the Student Records data base. 
Employees communicated changes to a personnel officer who 
updated the employee (Human Resource Management, HRM) data 
base. This information rarely got back to the Treasurer and 
Traffic name and address data base. Only through returned bills 
for traffic tickets, deferred notes, housing charges, etc. would 
these offices know that the address was incorrect. 

Social security numbers, used as the key in most campus 
systems, were also maintained independently from the rest of the 
campus data bases. During the registration processing cycle, 
Judy needed to match fee collections to credit hours to verify 
student fees. The discrepancies in SSN that had developed 
during the previous year made this matching process more 
difficult and time consuming. 



The Students 

Elhn, Nancy, and George meet in the LSU Student Union between 
classes. Ellen just got married and claims that her married name 
is already in her transcript but not on her student paycheck. 
Nancy is disgusted that her student loan check was sent to her 
old apartment even though the Phone Book has her new address. 
George is puzzled that his phone number is wrong in the Phone 
Book, even though he requested a change at registration. 

Before the centralized Directory, students were not aware that 
informing any University office of changes in name or address did 
not guarantee these changes would be effective across campus. 
Students might have had to report a change to five different 
offices in order to get all records changed. Their frustration, 
after repeated attempts to rectify the situation, may have caused 
them to abandon their effort to make the Univai»ity aware of 
their location* 



THE IMPLEMENTATION 

Now that we have described the environment and the problems 
that were afflicting many of our users, we need to concentrate on 
the steps we took to implement a solution. 

Armed with a request from the Office of Telecommunications to 
develop a system for their Directory Assistance operators, we 
embarked on a journey to produce a centralized solution for the 
University, 



LSU's development methodology breaks down the applications 
development life cycle into Requirements Definition, External 
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Design, Internal Design, Program Development, and Installation. 
At this time we were at the end of the Requirements Definition 
which establishes what needs to be done. But before we could 
proceed with the definition of the how, the External Design, our 
Director requested an initial assessment to concentrate on the 
following questions: 

o Could a solution be found that would fit the current 
systems and those systems currently in development? 

o How much effort would be required? 

_ o Could the implementation be staged in such a way so as not 
to interfere with ongoing development efforts? 

A detailed investigation was initiated to identify the primary 
systems using directory information. Eight out of 18 installed 
data base systems were managing this type of information: 
Admissions, Student Records, Independent Study, Human 
Resource Management, Traffic, Treasurer, Fee Bills, and 
Housing. Two of three systems in development would also be 
affected: Financial Aid and Telephone Registration. Fitting a 
solution that extracted information from that many systems would 
be a data management nightmare, so we concluded that the best 
solution was to develop a separate repository of directory 
information. This new data base should satisfy all requirements 
currently implemented in existing systems, and also serve as the 
source of information for the Phone Book and Directory 
Assistance. 

T'le AIS organization was divided into four groups: Development, 
Maintenance, Technical Services, and Str«itegic Systems. 
Following the installation of DB2 in 1986, and the success of our 
pilot project, the development group had a large inventory of 
systems in development. For this reason, this project was 
assigned to Strategic Systems. 

It was estimated that by using DB2, the major components of the 
system could be completed in six to eight months. These 
estimates also told us that about 85 percent of the effort required 
to develop the system would be changing existing programs to 
access the new d;^ta base. For this reason, and to keep the 
impact to our current development commitments to a minimum, the 
participation of the AIS maintenance group was deemed 
indispensable. 

The maintenance group responded with enthusiasm to our 
proposal. They were excited about doing work with DB2 and 
agreed with us about the many benefits that a project like this 
would have on the existing environment. 

Now we needed the cooperation of our user community. 
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Us«r Participation 

A meeting was called with user representatives from all 
departments involved. The agenda for the meeting included: 

o A description of the current environment and the inherent 
problems we had identified. 

o A proposal for an institutional name and address data base 
that would serve as a central source of information r all 



systems . 

o A description of the requirements that had been identified. 

Attending this meeting were six directors and ten Associate or 
Assistant directors reporting to five Vice-Chancellors from two 
campuses. The outcome of the meeting was positive. 

Users were then contacted individually. We wanted to make sure 
that all of their concerns were addressed. The following issues 
were identified in the interviews: 

o The implementation of the Directory should not significantly 
alter the screen flow of the systems interfacing with it. 

o Social security maintenance procedures should be part of the 
Directory system implementation. It was suggested that 
since most systems use SSN as the key to records on 
individuals, discrepancies in them must be minimized for the 
Directory system to be successful. Some users felt that SSN 
changes sho-jld be restricted and demanded weekly 
notifications of SSN changes. 

o Availability of SSNs through Directory inquiry should be 
restricted to "those who need to know" to discourage 
unauthorized access to sensitive information in the target 
systems . 

Since none of the issues discussed above would seriously impact 
the implementation of the system, a decision was made to proceed 
with the project. 



The Design of the System 

One of the first decisions that was made concerning the design of 
the system was the establishment of a model to interface with 
other systems. After some consideration, the Server/Requester 
model was chosen. With this model, the Directory system would 
act as a server and all the other systems would be requesters. 
The requester functions would be implemented in the form of 
subroutines that can be used by each system to satisfy their data 
needs. This model would give the system enough flexibility to be 
able to accommodate most requirements on a global basis instead 
of a system-by-system basis. However, we knew that we were 
O also committing ourselves to a very demanding development 
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and maintenance environment. All system needs would have to be 
satisfied by the Directory subroutines quickly to avoid delays in 
the implementation schedule. 

Once the model was established, our standard Entity-Relationship 
modeling procedures were followed to establish the data model and 
to define the contents of the DB2 data base tables (Figure 1.) 

The system was designed with the following features: 

o Access to information by SSN, spelling of the name, or 
sound of the name. 

o Quick display of name, title, organization, phone, and 

relationship with the University (i.e. faculty, staff, student, 
etc.) 

o Ability to handle requests for Directory hold so as to 

satisfy the Buckley Amendment and personal privacy issues. 

o Ability to keep a history of changes made to name and social 
security numbers to aid in the resolution of conflicts. 

o Ability to determine what systems carry information about an 
individual from a central location. 

o Ability to support multiple address types, but minimize 

storage redundancy when several address types share the 
same information. 

o Provide for decentralized maintenance of address data to 

maximize the chances of capturing correct information at any 
University office. 

At the end of both the External Design and Internal Design, all 
user representatives were given an opportunity to review the 
definition of the system. Later in the development cycle, the 
users were again brought together to discuss pre- and 
post-implementation procedures. We took every step possible to 
keep the users aware of our progress with the implementation so 
as to minimize conflicts. 

In the summer of 1988, the Centralized Directory became a 
reality. By far the most pervasive problems that we faced during 
the early stages of its implementation were data related. 
In deciding what information to load into the new data bases, a 
priority scheme was worked out so that information was loaded 
from the employee and student data base before any of the other 
sources. This created some confusion among the users whose 
data was preempted by a previous load. However, after a few 
hectic days, the users either changed the data back, or accepted 
the change, jnd soon settled down to work. 
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CONCLUSION 

We started this presentation by describing the environment that 
started this development in motion. Then we described the steps 
we followed in implementing a solution; the importance of user 
participation, the issues that we faced during its design, and the 
richness of the features that resulted because of this effort. 
Let s visit with a few of the players to see how they are 
managing today. 

Here is Libby looking at a copy of the 1989 Phone Book produced 
from the new Directory system. She says this is the earliest 
delivery of the Phone Book to the LSU community in years. 
Sandra is delighted with her responsive online Directory 
Assistance service. She is now able to make many of the phone 
and address changes directly and has retired her "master copy" 
of the Phone Book. And Ellen, now divorced, can finally rest 
assured that changing names is no longer «s difficult as changing 
husbands. 

Applications development starts with one user needing an 
automated solution for her/his business functions. Before you 
know it, you find yourself surrounded by lots of one-office 
solutions. What do you do? Face the issue. Integrate your 
systems, but in the process, don't forget to integrate your users 
too. 



40 



Figure 1. Directory Entity Relationship Modd 



Individual 




Address 



Address Type 



41 



517 



Out of the Blue and into the Black: 
A Case Study of MIDAS 



From time to time, promising applications of information technologies bubble up 
to the surface. Ideas for new systems can be the result of some new technology 
becoming commercially available, or they can be bom of previous efforts which 
didn't quite work. Sometimes these systems have no specific (read: traditional) 
owner or sponsor, that is, they are generic, community-wide information 
systems. At MIT, we beHeve that the IS organization must seize opportunities as 
they arise. We must carefully weed through all of the various possibilities and 
mo^ e swiftly to develop the most promising. The history of MIDAS, MIT's 
Infotmatioi. Distribution and Access System, is tJie story of just such a system 
This case study examine- the origins of MIDAS in previous failed efforts, its 
development history from a concept ("the blue*) and how it was ultimately 
transferred to a production service ("the black*). 



Timothy J. McGovem 
Senior Inject Manager 
Network Services 
tjmdmit.edu 



Mrr ^ Inlbnnation Systems 
Massachusetts Insti. .te of Technology 
Cambridge, Massachusetts 
November, 1989 
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L Introductiaa 



MIDAS stands for MITs Information Distribution and Access System. It is an electronic file 
service available on a public (i.e., ubiquitous access) timesharing machine operated by 
Information Systems. MIDAS can be used by any two people or organizations to securely exchange 
data. Access to the service software itself is not restricted, but access to the data placed there is 
restrictei' 

For the initial period, MIDAS has focused on solving the problem of moving data from central 
administrative departm-^nts (custodians or data suppliers) to Administrative Officers (AOs) in 
academic department and research laboratories and centers (data consumers). 

For a central department, MIDAS provid(<)s a single interface for data distribution for anyone in 
the community, without needing to bother with individual idiosyncrasies of the receiving user. 
Examples of custodians are Comptroller's Accounting, Payrolil or .rchasing. 

For a departmental administrator, MIDAS provides a single interface for receiving data from 
any of the many sources of data that they would normally need to work with individually. 

''Although the present implementation of MIDAS is not a long term solution, it is a pathway for the 
transfer of a fair amount of administrative information, quite adequate until: 

1. network authentication is available on the administrati> mainframes, and/or 

2. central systems invest in overhauling their data models to facilitate direct-inquiry 
access.^" 

MIDAS has the potential to, but has not yet, changed the way MIT conducts its business with respect 
to how data is moved between the central administration and academic or research units. In the 
non-coercive climate found at MIT, change often comes slowly. In the end, MIDAS can be judged 
to be successful if fewer custom ^stems are developed to distribute transaction data. 

"Without a business plan that everyone owns, bottom up projects [MIDAS is largely a bottom up 
project] can only go so far toward changing how we do business. Working bottom up risks: 

a. picking the wrong '1i>ottom" items on which to work 

b. going off oa tangents on one bottom item that worsens another.^ 



lemail communicatior. with M. McMillan, October 18, 1988 



IL Background 



ThelnfbrnuOionTechiudogyOrga^ 

The responsibility for the computing infrastructure resides within the Information Systems 
organization. A concrete definition of what constitutes that infrastructure is underway, but 
includes at the very least, the telephone ^tem, the campus data network, the supeicomputer 
facility, a set of shared mainfirames, both IBM and Digital Eqiidpment Corporation machines 
which are used for a variety of administrative applications, and a set of general-purpose 
applications. 

The Vice President for Information Systems is the Chief Information Officer (CIO) at MIT The 
responsibilities of that role are defined in a document entitlod Administrative Computing 
Principles for MII^. This document also defines the basic criteria that the Senior Vice President 
(and a Steering Commit!^) can apply when evaluating proposals for systems development 
projects. These principles (and their implementation) are expected to evolve as they are applied to 
a variety of projects. Two of these principles are important to understand in the MIDAS context the 
infrastructure responsibility and the call for innovation. 

The Principles reijuire that all organisations at MIT seek out and apply innovative information 
technology solutior:> whenever appropriate. Until October, 1989, one organization of the 
Information Systems group. Architecture & Strategic Technology (AST), was specifically charged 
to provide leadership in ^>is rogard. This group provided >uppo^'t to the CIO for innovative 
projects that did not hav^ other sponsors, or were purely conceptual. This group was responsible for 
the definition and development of the MIDAS sendee during the period, ^ril 1988 to Januaiy 1989. 
With the dissolution of AST, the responsibility for innovation has once again been distributed to 
each of the line organizationii in IS. 

Previous Efforts 

In the years that preceded MIDAS, various efforts b*ith at IvHT and elsewhere provided experience 
from which to draw lessons about what to do, and not to do. Typically, these projects were tactical 
exercises, dreamed up by one or two people often done with only minimal senior level support, 
usually done on a shoestring budget, and in technologies that *vere at the time not completely well- 
understood. TYiese factors pi educed projects that didn't fare all that well in the end. These projects 
sooner or later encountered either technological difficulties, or political difficulties, or both. Here 
are a couple of the prefects that the MIDAS project team learned from. 

Technological difffcisUies 

Several years before &iIDAS epp^^red, there was a project called the Statement Display System 
(SDS), and a companion project, the MIT Accounting, Purchasing, Property System (MAPPS). 
The former was a mainframe based database system containing huge amounts of financial 
information, mirroring the existing batch financial systems. MAPPS was designed to deliver a 
read-only version of the information with conventional micro-mainframe file transfer 
technology (usually at very low speeds) to an IBM PC. At that time, that information was available 
only on printed accounting statements. 



Sjames D. Bruce, Adminiatrftti v CompLdng Princinlea for MIT. August 1, 1989 



520 



At the tim^ of this project, many of the larger departments and labs at MIT already had invested m 
microcomputers of one form or another, and had begun to develop effective, if crude, office 
automation ^sterns for managing personnel, financial and other resources under their 
responsibility. SDS/MAPPS strode into this environment, and was one of the earliest attempts to 
marry mainframe and microcomputer technologies. Unfortunately, it did not meet all of the 
needs of its principal constituency, the administrative officers (AO) in academic departments and 
reseairth laboratories and centers, lacking among other things, the ability for an AO to run adhoc 
queries against the downloaded data. But the thing that really killed the SDS/MAPPS project was 
its poor performance. The value of getting some information, even if slowly, was not great enough 
to enough people to get them to change to a new way of Sleeping their books." 

Lesson leaned: System perftwrmtaioe ia a eigniflcanty neoessaiy hut not always iuflicient 
condition (tor suooess* Build systems in well-imderstood technologies^ sacrificing some function, 
to make sure that the resulting system can be tuned wifT^ 

Political difficulties: getting them touiyyes & really mean it 

In the summer and fall of 1985, Information Systems conducted a study that ultimately led to the 
publication of A Proposed Admmistrative Information Systems Strategic Plan^ in the spring of 
1986. One of the themes of the Plan was the need for widespread distribution of c^^ta from the 
central data stewards to the academic units. In order to study that problem, a Pilot Program (the 
Accessible Employee Database (AED) project was instituted to distribute Personnel data to the 
departments. Prior to this project, an administrator relied on two techniques to manage personnel 
data (or any other for that matter) in local offices, SneakerNet and rekeying of data from printed 
reports. Althoue^ the AED made some progress toward eliminating use of these techniques, some 
sixteen months later, the project final^ ground to a halt, for several reasons, -imong tiiem: 

1 . the project went on too long, and without a well understood project plan, expectations that 
had not been properly managed in the earliy stages gave rise to poor morale and 
suspicion. The AED project in fact exposed many problems, botii technical and 
organizational, which threatened the project's original scope and focus. 

2. the administrative of(i:ers who were participating in the pilot project had long been 
skeptical of the central administration's desire to lielp them" distributing data, and 
as time seemed to slip away, they felt vindicated and either dropped out or lost interest. 

Lesson learned: Keeppin^jectsdiort^warktoa veiy tii^tpindoctpl^ 

3. the project had produced too little, and too late, to maintain the interest and energy of the 
departmental representatives, and the IS representatives. Most of the people assigned to 
the project had volunteered 25% of their time, for six months, and were not generally 
being rewarded for their altruism in their home departments. The IS staff involve 
were still responsible for all of their normal work during the time that the pilot project 
was going on. 

Lesson learned: To the maximum degree possible, don't use volunteer help t^ do something 
KEALLYIMPOin'AI^ When ptish comes to shove, the operational smffhas to get done first 



^J. Bruce, I. Colbert, C. d'Oliveira, A Pinrvpn*^ AHm^nlata^tav Ynfarmfttimi Ryfmtm Strategic Plftiy January k« , 
1986 



4. the Penonnel Office was unable to maintain the level of commitment to the project's 
vision during a critical personnel change. One of the Plan'i principal authors was an 
officer in the Personnel office, and could make commitmento to distribute the Personnel 
data. Within six months of the start of the prqjecti that person had moved on, and with 
him, the Personnel Office's only understanding of the vision of the Plan. Although the 
pilot project continued for another year or so, there was never the same degree 
commitment. 

Lesson leamedL /Jianoes with any one organization can be perilous if the champion in that 
organfasHtion h at not tganaUBned the ^Wnerrfiip^ rftfia ormogit tn bityr M ym ig^t^ in w^^5^ 
he/lshe dta. 



As early as November 2, 1987, there was a MIDAS concept on the table. Given the demise of the 
Pilot Project effort, there were suggestions that any follow-on effi)rt in the area of personnel 
information should be based on a generalized piece of software (as MIDAS ultimately proved to be) 
rather than be a custom office-specific data delivery ^stem. 

Fortunately, most of the lessons above were heeded during the MIDAS project It helped that all of 
the developers of MIDAS had had direct experience with one or more of the cbove ^stems. So how 
did we proceed to a successful ^stem? 
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nL ^The Phoenix rises fixim the ashes^ 
The origina of the concept 

After a second round of negotiations with the Personnel Office that tried to keep the Accessible 
Employee Database project afloat had failed, the project was abruptly suspended in March of 1988. 
As we were in the process of taking stock of what we had that could be salvaged from the Personnel 
project, and as we were looking around for new and interesting stuff to work on, fate intervened. 
There were a number of efforts going on around the now suspended project At about the same time, 
the Financial Operations group had received a request for information from an influential 
member of the Strategic Plan's Advisory Council. Confluence also came in another form. Yet 
another group of AOs had been discussing ways that they could, woiking as a grassroots 
organization, build a personal computer q[>plication to manage the books of their (mostly research 
oriented) organizations. They petitioned for, and received, support for the idea from the office of 
the Vice President for Research. Thus there was a growing amount of pressure to begin tu 
distribute important data* The Comptroller's effort had already done some preliminary studies 
and found that the SDS^ifAPPS solution described above was not the answer, and they were getting 
ready to start to develop *son of SDS/MAPPS," another custom data distribution system. 

The Vice President for Information Systems gave the go-ahead for a ''proof of concept** project for 
an infrastructure service that would make the efforts of the groiq>s mentioned above more 
efficient. This type of project solves most of the problems of the projects described above, as it limits 
the scope and duration of a given project, and use the "prooT as the mechanism for recommiting 
resources. With this charge, we approached the CbmptroUer with the idea of doing a joint 
development project. We proposed to develop and deploy a general-purpose data distributor system 
drawn from the technology developed in the AED. This system could then become part of the 
infrastructure. This would fi'ee tiie Comptroller's staff to develop any specific financial 
application software, on the mainframe or on microcomputers, that might be needed. As it has 
turned out, there are three application systems now in various stages of completion. The first is a 
fairly extensive mainfi*ame-based system that permits AOs to examine, summarize and produce 
reports on their data in a variety of different ways. The data used is first retrieved fi*om the 
MIDAS server, but left in a user^s mainframe directory) rather than downloaded. The other two 
systems are personal computer based ^stems, one for the IBM PC family built using the Rbase 
product, ^he other for the Apple Macintosh family built using the 4th Dimension product 

Within three weeks of the initial idea, we had established the MIDAS Project organized upon the 
following principles: 

* Owner: the Vice President for Information systems is the nominal "owner^ of MIDAS, 
in his role of CIO. 

^ Custodians: no single custodian manages the MIDAS facility. Any recognized data 
ste ;/ard can make use of the ^stem, for the price of thf storage. To the maximum degree 
possible, a custodian should be self-sufficient. Although custodians alone can decide 
what they will distribute, clearly they aim to be responsive t<o the stated needs of the AOs. 

* Subscribers: no single data subscriber's needs are more important than any other. The 
system aims to make data available to all platforms via use of commonly available 
protocols. 



^Our chosen development methodology, Produgtivity Plim. fW)m DMR Group, Inc. includes a veiy precise 
meaning for *owner." A system owner is the person or perMms who pays for l^e system, who therefore is 
entitled to making the go/no-go decisions. 
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• Development: the system would initially be built with existing tools and software 
products, and include an API toolkit for use by custodinn-provided appUcations. 

• OperationK the sj-stem should not require additional operations, production control or 
other administrative personnel. That is, it should not require intensive administrator. 

WiatU is & what problem it i$ trying to wolve 

MT* \S is a "smarts file server that providos a single, consistent interface to data providers, and a 
8in„.e, consistent interface to data subscribers. Its "smarts" derive from the fact that unlike some 
other data sharing mechanisms and file transfer sch»<mes, MIDAS "knows" what files it 
currently has stored, and the diaracteristics of each file, such as the name and type of each data 
field. Its most important features are: 

• providers are insulated fit)m the needs of any single subscribers' workstation type and 
software 

• suUcribers are insulated from the existing data formats of any single providers' 
mainframe database system or application 

• subscribers can request onfy certain fields of a given file, and in a particular sequence 
to aid in loading into pre-existing applications (both on microcomputers and 
minicomputers) 

• providers are responsible for maintaining the definitions of their files, and a list of the 
recipients of those files 

• thbfe are hooks for custodian developed application software 

• access to the system for all of the above is ubiquitous. 

'nie'mie green light^ 

The development team was given a challenge-the entire development cycle, from concept 
exploration, through analysis and design, programming, testing and documenting, would 
consume no more than 2 monllxs, approximately 11 weeks fit)m start to finish. This is what we 
have since referred to as the "little green Ugjit" Needless to say, we were going to have to be very 
judicirius in our use of time. UnUke previous efforts, this one would not start out with an miUmited 
time horizon. This ultimately had the beneficial effect of Umiting the resources that were poured 
into this prqject, both in the ho^inning and over the long haul. 

The guiding principle for the project was this: fulfill a simple need with a simple product The 
first version could be veiy crude, but it must be respectable. On the pragmatic side, we needed to get 
financial data to users more easily than it was then possible. We decided that quick tuma -ound 
prototypes would be necessaiy. As a guiding principle, we beUeved that throwing away a couple of 
prototypes was not tragic. Throwing away the user interface would have been tragic. To do it a 
"piece at a time," doing whatever proved to be usable and possible, was the right next step. 

Sedting *inx)ofofconcept^ 

The MIDAS Project Team was given the go-aliead with the proviso that we could p^-^ceed until 
"proof of concept" or until it was clear that this product wasn't going to work any better than 
previous ones. Throughout the development period, we tried to define carefully just what this 
"proof of conceptr would mean, and how we would recognize it when we saw it. In the end, "proof of 
concept" is veiy much in the eye of the beholder, but the better the beholder, the better the proof. 

We allocated the time we had in the following way: 
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• 


Weekl: 


Sell the idea to potmtial data stewards 






Explore the eoneept 


• 


Week 2: 


Complete eoneept exploration 






Do analysis of system in its entirety! 






Start technical design of lystem 






Start prototyping in several key technologies 


• 


Week 3: 


Complete tedinical design and hold design review 






while prototyping continues 


• 


Week 4-7: 


Build, testy and deploy server code 


• 


Week 6-8: 


Buildt testy and deploy client code 


• 


Week 7-10: 


Complete QA and documentation 


• 


Week 11: 


Deploy lystem officially; receive initial data feed from pilot custodian 



DefinUian of the system 

One of the difficulties that immediate^ faced the development team was how to read consensus on 
the features of a system when there wasnt really a traditional owner. It was fortanate that the 
development team had participated in the previous attempts to distribute data at MTT, and 
understood some of the obstacles that had been encountered. For that reason, we decided to take two 
different ^acks to the ultimate lystem. The first tack would be to use conventional ^tems 
analysis techniques, with the development team playing all of the roles of a typical ifystems 
project, botli the customer and the analyst At the md of a week of sometimes ezcrudatini^y long 
interview/dnsign sessions, we emerged with a i^stem design that remarkably enough remains an 
effective det^^gn document even now, some 18 months later. This design was presented, reviewed 
and approvdd at a formal design review meeti:ig at the end of Week 3. The second tack was rapid 
prototyping of the item's client and server Ainctions. In order to do that effectively, we needed to 
choose a development environment that was familiar to the developers, rich onou^ in tools to 
permit such rapid prototyping, and that would ultimately be robust enough to act as a platform for 
(he emerging service. We found that all three of these conditions were met by the only ubiquitously 
accessible mainframe on the campus for general purpose time-sharing access, an nM 3083 
running VM/CMS. The system was prototyped and ultimately deployed almost entirely in the 
VM/SP System Interpreter language REXX, with a few routines written in PL/I for the sake of 
efficiency. 

Development of the wystem 

The use of proven technologies frc a the outset probably did more than anything else to ensure 
completion within budget and on time. In this case, the innovation was largely in terms of the 
organizational impacts of the system. 

Bui even in a progect that is using off-the-shelf technology, you need to have some way to capture 
and manage the results of the many brainstorming sessions that are inevitable in a development 
group. K simple "Futures" list, maintained electronically and shared frequently with the 
development team, worked very nicely. The MIDAS administrator still uses this list for planning 
purposes. 

Our original goal was to have a single group provide sole support for all MIDAS-related activities- 
-design, development, maintenance, training, documentation, support, marketing, planning. 
This would mean that there wore far fewer comn unications paths to handle on a day-to-day basis. 
In the course of the prototype phase, we found that > ^e n^ed to bring in a few other groups to resolve 
problems or provide additional support where the expertise did not exist inside AST. The fo^t that 
we had already briefed the Vice President and his di/ect reports (directors of the vaiious 



Information Systems departments) meant that we weren't delivering any surprises to the other 
(eventual) support organizations. 



Given the ti^t sdiedule, we decided to limit the group that could provide functional input to just a 
few users and one eager custodian for the pilot stages. 



Providing support to users while still developing the system could have swamped the development 
team. We decided to gruom the initial set of four users so that they could then provide some limited 
forms of support to a larger (16-20) group of users. We put in place a Tniddy system" between the 
•expert" AOs and the large group. Administrators are already more likely to call another AO for 
help with some type of administratWe procedure questions than they would call anyone in the 
central administration. 



Deployment of the system 

The responsibility for choosing test subscribers was assigned during the "proof of concept" phase to 
the initial custodian. One of the issues that was batted around quite a lot was whether this group 
should include experts, that is, experienced computer users, or a group that was more 
representative of the community at large. Support for the former was predicated on the idea that 
what was fiot needed during the pilot was a lot of problems of siq)porting n^ce users, that the proof 
of concept was not on how well the system could be deployed, but rather on whether data distribution 
could work at alL Tlie "representative* argum \ was that proving the data distribution could 
work for savvy computer users was no proof at all, that the real pudding that needed testing was the 
relatively inexperienced personal computer user. There was passion on both sides, but in the end, 
we decided to go with mostiy experiencsd users, and to use the buddy system for less savvy users, to 
keep the demand for support from the central organizations fairty low during the pilot stage. 

Reaching ^^mxjfofconcqO^^ordeckaing ^imccese^ 

By the end of calendar 1988, we had generally proven that the concept was viable, and our project 
was judged a SUCCESS. In the course ofthe project, we discovered a number of things. In 
summary, we found that: 

• it is techrJcally feasible to construct in a short time a *smarr data server to accept and 
redistribute MIT's administrative data using off-the-shelf components 

• administrators will need to (and will if allowed to) connect to data distribution services 
in a variety of communication modes, and at speeds far exceeding 1200 baud, including 
high-speed access over the MITnet 

• custodians do not have to be responsible for maintaining *user profiles" that tell them 
what kind of machine, software, etc exists on each user's desk 

• custodians do not need to generate ''special purpose" files where those files are merely a 
subset of the data fields found in an existing 'Wster^ file 

• custodian effort can be kept relatively low (for the reasons in the previous two findings) 

• users found the initial threshold low enouc^ to warrant tlieir continuing in the project 

• launching custodian applications fh>m within the data distribution system has both 
rewards and hazards on a number of dimensions 

• data distribution is a necessaiy, but not sufficient, condition for the integral and 
effective use of information in departmental offices. The lack of workstation-based 
applications to process these data was a migor limiting factor to the overall data 
distribution service. 
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Infonnation 3y«tems has fbnnalized the process of bringing a new (not anticipated by the 5 Year 
Plan) service to the campus* The primaiy instrument in ^is process is a Service Plan. Among 
other things, the Service Plan describes the benefito of the service, the service's ol]gectives, provides 
an assessment of the demand and need for the service, risks, alternatives, estimates resource 
requirements, and suggests possible metrics and evaluation criteria* The Service Plan is 
typically presented by a Service Champion, and reviewed by the IS management team. 

Finding the most appropriate 'service champion," and working with them on the Service Plan 
were therefore our next nugor steps. The MIDAS team began by developing a number of scenarios 
for the transfer from "proof of concept" to production. This included placement of the marketing, 
custodian and consumer support, and qrstem maintenance and enhancement ftinctions. We 
reached agreement with the Production Services manager that his group should be the Service 
Champion. The scenarios also called for a variety of different levels in the expansion of the user 
and custodian base in coiqunction with the other support areas. These scenarios were presented to 
the IS management te^n in December of 1988, at which time the decision was made to pursue a low- 
growth option for the initial 12 months (lOU^ly calendar 1989), calling for 26 new users, and 5 
more custodians. 

A m^Jor prerequisite for the wider deployment of the flystem involved the establishment of 
"computing budgets' for the academic departments. Althou^ this mig^t not appear to be a major 
proUfim to some, there was litUe history of the use of central computing resources by these 
departments. The situation was fivriher complicated by the overhead structures of these 
departments versus that of the central deparbnents. In the end, it was decided that a portion of the 
central computer that hosts the MIDAS server, and in turn provides user access, woidd be allocated 
to academic departments and research labs ft centers. This took the form of a BIIDAS Grant 
Program, where each participating AO applied for a grant of monies to use the MIDAS (and 
related) systems. The NODAS Grant Program is administered hy the Production Services 
manager. The individual grants are monitored by the Administrative Officerf in each 
participating unit 

Transferring technology 

The Service Plan called for the MIDAS development team to train the new team that would be 
responsible for administering,and maintaining the q^ftem. This was done using a series of 
seminars and workshops during January and February 1989. During this same time, day to day 
r isponsibilities were being transferred to the new administrators in ^Se Production Services 
group. During January, the original team constituted the first line of support with Production 
Services Vatching* over 'Hir shoulders. During February, those roles were reversed. On March 
1 , 1989, the original dev ^^ment team was no longer involved in day to day support 

Finally, we transferred the resp .nsibility for the documentation products to the Production 
Services group. These products were: 



User^s Tutorial 
Technical Guide 
Custodian's Guide 



User's Quick Reference Guide 
Administrator's Guide 
General Information Guide 
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IV. Conclusians 

Fnmi eveiyftdlura^ there «TO Tl^ere is no question but that the 

experiences in the several years prior to the MIDAS project provided the MIDAS development team 
with a number of insii^ts and techniques that enhanced the project's chances for success. 

Not eyeqihiiig that srcm touch wffl Chanpng the wqy large, bureaucratic 

organizations conduct businest^ takes a long time. No single technology product is likely to 
instantaneously alter the business of MIT. MIDAS is just one component of many that together 
can make MIT a more effective and efficient enterprise, and a more enjoyable place to woik. In 
particular, the lack of personal computer based applications, which would create a greater demand 
for downloaded data, has kept usage of MIDAS lower than anticipated levels. 

Data deflnitioii is our Adiillas heeL We needed to open the kimono about the problems that esdsted 
with inconsistent data definitions. Again and again, MIDAS (and previous efforts) risked 
running aground when the data was not of sufficient quality to be shared with departmental units. 
The fear of sharing «ub8tandard data was that it would put new and intolerable demands on the 
support resources of the central offices. 



Marketing ia key. You can't assume that in the hustle and bustle of everyday life, that new ways of 
doing business (regardless of how good they are) will be adopted instantly. You must continually 
market the usefulness of the system to both existing and potential, subscribers and custodians. In 
particular, it appears that it would have been a good idea to have provided for a consultant whose 
responsibility would have been to work closely with all of M^Ts data custodians to make 
additional information available. 



Source Data Capture* Electronic capture of administrative data at the desktop and deliveiy to the 
appropriate custodial organization may ultimately be whaf s required to change the way business 
is done. 



Be lucky! 
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A Voice Bulletin Board System for Career Placement 

by 

Norman L. Thienel 
University of Virginia 
Charlottesville, Virginia 



ABSTRACT 



The Office of Career Planning and Placement at the University of Virginia 
has implemented a voice bulletin board system to electronically post verbal 
announcements for job openings. Registered users can access the 
computerized system by calling from any telephone equipped with touch-tone 
dialing - no other equipment is needed by the caller. The bulletin board 
system automatically answers calls, requests the caller to key in his 
identification number, and then recites job listings matching the career and 
geographical interests of the caller. The system runs unattended around the 
clock, except for an hour each weekday w g when database information 
is updated. Out-of-date jobs are automatically removed from the database, so 
all information relayed to the caller is current. The VBBS user benefits from 
remote access to valuable information, and the only cost accrued by the user 
is paying the phone company for any long-distance calls. 
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A Voice Bulletin Board System for Career Placement 



Introduction 

The Office of Career Planning and Placement (OCPP) at the University of Virginia in 
conjunction with the university's Administrative Computing Services have implemented a 
voice bulletin board system to electronically post announcements for job openings. Registered 
users can access the computerized system by calling from any telephone equipped with touch- 
tone dialing; no other equipment is needed by the caller. The bulletin board system 
automatically answers calls, requests the caller to key in his identification number, and then 
recites job listings contained in the database that match the interests and qualifications of the 
caller. The system runs unattended arourd the clock, except for about an hour each morning 
when the database files are updated. 

Among the extensive computing facilities at UVa, is one very important one located in the 
^rpp office. Since 1986, OCPP has been using a 13-station PC network to support its efforts 
to assist students in planning and choosing career fields. Nonetheless, before the advent of 
the voice bulletin board system (VBBS), OCPP had to collect paper documents announcing job 
openings to make them available for review by interested job seekers who studied, lived, or 
worked in Charlottesville. The information, although potentially of interest to a large number 
of people, was not readily accessible to many who could have benefitted from it. To have 
access to this information, a prospective client of OCPP had to either visit the office in person 
or telephone a staff member to request information. In effect, the data was available only 
within Lie walls of Garrett Hall, the home of OCPP. 
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A manual filing system was used to organize and maintain the documents and to dispose of 
those that became out of date. This method was slow, cumbersome, and labor-intensive. 

The new VBBS provides remedies for each of these two inefficiencies, offering significant 
advantages to both job hunters and to the OCPP office itself. The VBBS uses a conventional 
computerized database sysrem to select and present jobs listings that are of specific interest 
to the caller. Out-of-town and even out-of-state alumni can access the database around-the- 
clock. Callers are able to "page" through the jobs by using any touch-tone as the signal to 
interrupt the computer's speech and to go on to the next option. AH job positions that entered 
the system prict to the caller's last call are suppressed, unless the caller asks to hear all 
matches, regardless of when the job listings entered the system. 



Benefits to ihP i ;;aMt^r 

The VBBS clients are scattered about the country. When a job seeker calls, selections are made 
on the basis of the geographical preference indicated when he registered to u»e the VBBS. If 
the caller ever wishes to select on the basis of a different geographical legion, he may utilize 
the on-line o.-Jtion to change his geographic preference, and then ask the computer to restart 
the matching process. At the opening voice menu, a caller can choose between heaiing all 
matching jobs, or only those that have been added to the database Since his last call. Cut-of- 
date jobs are automatically removed from the database, so all information relayed to the caller 
is current. The VBBS user benefits from virtually instant access to information, and his only 
costs are a nomin-' -cgistration fee and then paying the phone company for any long-distance 
calls. 
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Voice quality of prc-rccordcd speech played by the VBBS is indistinguishable from a live 
voice. The system is very simple for a caller to use: a voice menu is presented after each 
VBBS function completes. An introductory message is giv^n to all first-time callers explaining 
the operation of the VBBS, and the system offers on-line help messages that can be requested. 

When a job seeker calls the system, the VBBS software identifies the caller by his ID number 
(SSN), finds his data record, and makes note of the values for the three parameters on which 
it must find a match: major, geography, and career field. Then the job listings are searched, 
and when one is found that has attributes corresponding to those desired, the pre-recorded 
speech file lepresc ting name of the employer, the job title, and the short description is played 
to the caller. The caller can then have these items repeated, have a longer, detailed dc^^cription 
played, go on to the next job match, or return to the previous menu of choices. And at any 
time during the playing of these speech fiies, the caller can interrupt by pressing a touch- 
tone, and the system will respond by playing the menu (which can also be cut short by the 
caller pressing a key) and asking fur the caller's next menu choice. 

Benefits to OCPP 

This system provides a vehicle for OCPP to distribute valuable information to its client base 
in a timely and efficient manner. Using the features of the DBMS, OCPP can easily monitor 
usage of the system, knowing exactly who calls and how often, and which jobs are most 
frequently matched. The unattended system is available to callers for 23 hours a day, and at 
an opera ing cost that involves only the manpower required for entering the new data each 
day. (Out-of-date data is purged artomatically.) The reputation of OCPP is enhanced because 
both employers and prospective employees recognize the effectiveness of the system, and usage 
by one group encourages greater usage by the other. 
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Development of thP ^^^t^ 



The design, programming, and implementation of the software for this system was performed 
by Administrative Computing Services at the University. The telephone management 
functions needed to answer the phone, accept input, and play voice files were provided at the 
dBASE programming level by dbSpeaker(tm)^ Because the VBBS system is essentially a dBASE 
database system, development time is short and the effort is very much like conventional 
dBASE programming. In fact, much of this system's program code was developed befoie the 
arrival of the Watson system by using keyboard input and screen output to simulate telephone 
input/output (I/O). Then, when the Watson voice sub-system did arrive, it took only a short 
period to convert terminal I/O to telephone I/O. However, interacting with a telephone caller 
does present several complicating issues because of concerns with time-outs for input, having 
touch-tone input interrupt speech, and handling situations where callers hang up in the midst 
of a session. dbSpeaker, though, does provide useful tools to integrate the features to 
conveniently handle these situaiions. For instance, when waiting to read touch-tone input, the 
VBBS dBASE program passes to dbSpeaker a parameter defining the time period to wait before 
"timing-out", the caller does not respond in the allotted time period and there is, in fact, 
a time-out, the program tries again by repeating the question two more times if necessary. If 
there still is no response from the caller in the way of touch-tone input, the VBBS will 
electronically hang up the phone on its end. This is necessary because there is no direct test 
available to sec if the caller is still on the line. Consideration was also given to not allowing 
the total length of the call to CAceed some value, say 10 minutes. But it was decided that 
because most callers would be paying for long distance calls, it was not necessary to limit call 
duration. If, in the future, this feature becomes necessary, it will be a simple matter to alter 



dbSpeaker is one ( omponent of the Watson(tm) voice sub .,ystem that is a product of 
Natural MicroSystems Corp. of Natick, Massachusetts. Other required components for this, 
application arc a Watson interface board that resides in the PC, and two other software 
products from Natural Microsystems. 
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the program to note the time the call began, and to periodically check to see if the caller's 
daily limit of on-line time has been exceeded. 

A.!though the Watson sub-system can output synthesized voice messages for variable data (e.g., 
values for a job title, name and address of an employer), it was decided to verbally record 
all data that is relayed to callers instead of keying it and letting the Watson voice system 
synthesize it. This approach yields a couple of significant benefits. First, there is far higher 
quality for the system's output as every message heard by th*^ caller is a reproduc on of a 
human voice. (The image of the voice is stored digitelly, and it can be reproduced an 
indefinite number of times without any distracting backgroi d noise.) By using recorded 
speech for the job listing information, the vLice output is much clearer and the task of data 
input is made easier. The datt input module was written to accept the spoken word for job 
data fields such as job title, name and address of employer, short and long descriptions of the 
job, and name of nerson to contact. Thece data items are then entered into the system during 
its one hour of off-line time each day by speaking thwin into a telephone dialed into a data 
Ciitry program running on the VBBS PC. Speaking these descriptive items into the syst m takes 
much less time and effort than keying them. Voice data is converted by the Watson system 
into digital data which is stored as disk files. Data for geographical location, career area, and 
required degree still must be keyed; these value are used for the dBASE matching algorithm 
and therefore must be present in the employers' database file in a standard dBASE format. 
These values are never directly relayed to the caller, but instead are implicit in any job match 
data spoken to the caller. (It was also decided to key the name of the employer in add-tion to 
entering it verbally. This allows historical reporting to include data on company names.) 

A standard IBM-compatible PC is an adequate platform for implementing a VBBS application. 
However, it should be noted that if job data is stored as digitized speech, the disk space 
requirements become substantial. The dbSpeaker software uses a default speech compression 
rate of 3 Kbytes per second when recording voice data to disk, so a five-second message, for 
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instance, will require 15 Kbytes of disk space. If each job has a job title, company name, short 
job description, long job description, and name and adUi ess/telephone number of a contact 
person, and then several hundred job descriptions stored on the system may require more than 
50 Mbytes of disk storage. Considering this along with our expectation to upgrade the system 
in the future to accommodate multiple, concurrent incoming calls, an 80386- based PC equipped 
with s 60 Mbyte fixed disk was selected. 



Reaisterinq the System Users 



Students ami alumni who wish to gain access to the VBBS are required to submit a completed 
application form to OCPP. On this form, the individual specifics his academic major, his 
career field interest, and geographical preference. To simplify the task of data entry at OCPP, 
each applicant writes on the for:i> the actual code corresponding to his each of these three 
items (the entire set of codes is lasted on the application form itself >. Prospective employers, 
on the other hand, submit their hiring requirements on documents whose form and content 
vary widely. Therefore, keying this data often involves some decision making for the career 
field area or field of study. If the employer does not specify any majors that are required for 
the job, *2iRy' is entei-ed and this will match v ith all stulent majors. 



Management Reports 



Because the system is essentially an automated dBASE database, it was a simple matter to 
program the usual report features that tell OCPP management about the usefulness of the 
system, and the characteristics of the clients who utilize it the most. Daily reports contain 



data for percent of time the system was in use, number of calls received, number of matching 
jobs found, number of students registered, number of students deleted (when the three-month 
registration period expires), and number of jobs currently listed. Other reports that are useful 
over longer intervals are number of calls received during the period; number of different 
callers using thr system; and total number of positions that have been advertised. Reporting 
options can also list which career fields, majors, geographical areas have yielded the most job 
positions, and which employers have listed the most jobs. Another report will produce mailing 
labels for all employers who have used the system (provided employer address information has 
been keyed). 



Future Plans 

As demand for this system increases, a multi-tasking system will be installed along with a 
second phone line into ihc system. If the caller load begins to tie-up the two-line system, then 
a network will be installed and the current machine will be converted to the file server. 



Another potential new feature will be the implementation of a voice mailbox so that callers 
can leave voice messages concerning problems or suggestions for OCPP to review the next 
business day. 
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A Counseling Reservation System in a Local Area Net*«rk Environment 

Bruce L. Rose 
Ciorahoga Conmunity College 
Cleveland 
Ohio 



Abstract 

This paper will discuss the development and 
implementation of the Counseling Reservation System 
developed at CiQrahoga Conmunity College. In addition, 
the paper trill discuss future plans for automation and 
Information Systems in the counseling and student 
services area - specifically, the expansion of the 
Metropolita LAN and applications to CCC's Western and 
Eastern caii|)usps. Finally, this paper will analyze some 
of the inherent problems found when introducing networked 
departmental computing into the College's offices as a 
case sti'iy which nay benefit others following this same 
path. 
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I. Introduction 



Ciiyahoga Coanunlty College Is a large two year Institution which 
serves the greater Cleveland area In northeast Ohio. The College Is 
composed of three distinct canpuses and a district administrative 
office. The three campuses - Metropolitan, Eastern, and Western - 
vary In size, and composition of their student body but all three 
remain subordinate to the one "College" both organizationally and 
operationally. 

CCC has aggressively pursued a leadership role In both administrative 
and academic Infomntlon systems (IS) and computing, thus there are 
numerous IS Initiatives which contribute to the College's strategic 
mission of academic quality, access,, and success. One of these 
Initiatives Is the Introduction of automation and networking to the 
counseling mi advising areas cf the College. 

Beginning In 1986, a "pilot" local area network (LAN) and 
telecommunication capability was Installed In the Metro campus 
counseling area In onfer to evaluate the effectiveness of providing 
both local resource sharing and host connectivity to the counseling 
staff (about 18 counselors.) The results were Impressive In that most 
counselors used the electronic mall and word processing capabilities 
of the LAN In their dally work, and there was a general clamor for 
additional training, software, and resources. 

In particular, the computing consultant (the author) and the director 
of the counseling area agreed that the key enhancement need for the 
LAN was some type of scheduling or appointment capability which would 
be accessible by all of the counseling and clerical LAN users. 

A simple scheduling system was In use which provided batch reports of 
counselors' dally schedules as well as student record request lists. 
This Scheduling System originated from a timesharing application on 
the Honeywell/Bull mainframe computer, and was migrated down to the PC 
using dBase Ill's development language and database format. This 
simple Scheduling System would form the basis for the Counseling 
Reservation System which was Jointly designed by the counseling 
director and the author. 

The resulting application, the Counseling Reservation System, is 
operational at the Metro campus and will soon be migrated to the other 
two campuses. The system Itself, has many merits and some weaknesses 
and Is well liked and exploited by the users. 

The development and Implementation of this application will be 
explained In the f^^^lowlng pages and represents the primary theme of 
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this paper. A secondary thane of this paper Is to discuss the 
Reservation System development and Its Importance to the overall IS 
strategy In the Student Services and support area of the College. 

There are some Interesting characteristics of this system's 
development, i4i1ch are also discussed. For example: 

1] The scope of the system was technically and functionally 
conservative and was delivered rapidly to the user 

2] The system was a literacy tool for both user and developer, 
and would be used to guide larger and more ambitious 
development efforts 

3] The resource requirements were minimal and could be absorbed 
without coninlttlng or delatying other formal development 
projects 



Section II Is a discussion of the system development; section III 
discusses the Iraplement-tlon of the Reservation System, and finally 
section iV concludes by sumnarizlng what was learned In this 
development and how others m^^y benefit from this exper* nee in small 
systems development. 



II. Development of the Reservation System 

The Counseling Reservation System grew from a s1mpl« scheduling system 
which was first developed on the Honeywell/Bull mainframe computer 
used at the College. This system was later migrated to an IBM PC 
application using dBase Ill's file format and application development 
language (ADL). kk h- 

The scheduling system simply accepted appointment transactions keyed 
into a specific format, and later collated these Into dally schedules 
and other reports which were used for requesting files from the 
records office. 

The counseling director came to the computer center with the Initial 
concept of a real time scheduling or appointment system which would 
eliminate the need for a manual schedule book. He had the following 
parameters to work with: 

0 About 18 full time and a few part time counselors; his staff 
generally worked fi-om 8;30 to 5:00, but there were 
appointments taken In the evening from 5:00pm until 8:00pm 
and a small staff on Saturdays. 
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0 Each appointment was 30 minutes In duration and was handled 
one on one with a counselor and student. 

0 There were numerous other "types" of time commitments for 
which the counselor would be assigned Including walk-In 
counseling during registration periods and student 
cr Habitations. In addition, the coinselors enjoyed faculty 
status and might be teKhIng a class or have other academic 
coMltments. 



0 For scheduled appointments, the director closed out the 

scheduling about 3 or 4 working days ahead of time. That Is, a 
student could not nonnally make a scheduled appointment with 
less than three d^s lead time. This allowed the office 
schedules to be collated and distributed, and allowed the 
records office to deliver the students file folders to the 
counseling office. 

In terms of design, we agreed that the technical problem of automating 
a schedule matrix would be solved first. The author completed the file 
design and a simple scheduling program or algorithm which would accept 
a time range stateu In normal clock hours (e.g. 8:30am or 10:00am) and 
"map" or translate this time range Into the scheduling matrix. 

The scheduling matrix or table looked something like this when 
completed: 



Qatfi CwnselPr Time slot #1 Time Slot 12... Time Slot l<n> 

04/11/89 JN a CC 

04/12/89 JN XX 

04/14/89 m CC 

The time slots represented 30 minute time comnltments, while the 
two-position code (e.g. CC, XX) represented the "type" of connltment; a 
blank, of course, meant the time slot was open or available. 

This worksheet style matrix had the advantage of being very straight 
forward and lent self very well to display and visual Inspection. 
The Intent of usage was clear at this point, and would follow the 
following events: 

0 The student would approach the front desk or call the 

counseling office to make an appointment to see a counselor. 

0 The operator or clerk would glean the Intent of i\)e appointment 
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(type), and If the student had preferences for the counselor 
(Mho?), the time or date (When?). 

0 Armed with these preferences the clerk would query the schedule 
matrix and visually determine the best fit for the student, and 
schedule the appointment. 

The k^y to this "point-of-sale" process was providing the strongest 
possible visual representatic;j of the schedule matrix on the limited 
size and resolution of the Personal Computer screen or monitor. We 
determined three separate queries or visual displa^ys would be 
necessary: 

0 A query by date. This displayed the schedule matrix and time 
slots for all counselors for a given date. The table could be 
"scrolled" or moved forward and bactcward in time using the PC's 
cursor control . 

0 A que;y by counselor. For a student who wanted to see a 
particular counselor, this displv would show all available 
dates for one counselor. 

0 A query by BOTH date and counselor. For a student who had both 
a date and counselor of preference, this query would zoom in on 
the specifics of an individual daily schedule. This, by the 
way, was the same query which produced the daily schedules for 
the counselors. 

The terminology. Reservation System, is best represented in this part 
of the application. The director and author envisioned an airline 
reservation clerk interacting with a coirn'i' r terminal display to 
accomplish reservations. Speed, accuracy and customer satisfaction 
would all be dependent on how efficiently and effectively the comuter 
would visually bring forth the needed schedule information, and how 
the clerk would navigate to the desired "best-fit" between customer 
need and availability. 

This was the most difficult part of the design in that beating or 
equaling the manual process (i.e. visually inspecting and updating the 
manual schedule book) was a challenge. If we could satisfy ourselves 
that we had at least equaled the manual process, we knew that the 
other benefits of the system would warrant a full implementation. 

The system, was developed along these lines. A computer center 
analyst implemented the author's time scheduling "engine" and 
completed the application in about 3 months of part time involvement. 
The system was tested stand alone at the counseling front desk, and 
the manual scheduling book continued in use as the authority 
information. The preliminary results concluded that: 
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0 There was a rather high rate of data entry errors. In 
particular, an Incorrectly coded student number (social 
security number) would Introduce duplicate and erroneous 
records Into the system. 

0 The visual representation of the schedule matrix was still 
inadequate for effective scheduling. 

0 The scheduling time engine worked as advertised, and the 
resulting time savings wore very good. 

The most critical enhancement of our second testing phase was to add a 
significant database overhead to the system, namely the student 
authority file. 

We agreed that we would c&jfmse, extract, and maintain a file of all 
registered stude ts at the local campus to be used In tho Reservation 
System. The source of this file would be the mainframe based 
Integrated Student Information System (ISIS). This addition would add 
significant complexity and overhead to the system, but would solve our 
data Integrity problems and would create an Interesting tracking 
dataset which could be queried statistically In the future. The 
addition of this coirponeRt of the system had the following 
characteristics: 



0 This would be an operational datab^re. The Information would 
be extracted and transferred to the K or LAN, as opposed to a 
realtime interaction with ISIS. 

0 The authority student information would be linked to the local 
counseling information such as number of appointments, 
counselor last seen, and cancellation or no-shows. 

0 The file would be cycled on a quarterly basis. Students who 
had an appointment history would be retained, and the "age" of 
the student's experience with the counseling office would also 
be tracked or known. 

The addition of this file, meant that the clerk could assume the 
properly registered student kould be "known" to the system. This 
saved keystrokes and added greatly to the data integrity of the 
student appointment file. The student could be told of what the 
"system" recorded as their current demographic and address 
information; thus, changes or inaccuracies would be quickly reported 
back to the records office. 
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This authority file was Implemented and to date we have one ~nd 
one-half years of tracking infonnation In the file. The preparation 
and transfer or "downloading" of the authority file Is soneMhat 
formidable (about 5-10 thousand records of 200 characters each), but 
once the file Is operational Ized the capacity of the local software 
and hardware Is not really challenged. 



Ill Implementation of the Reservation System 

The formal 1^)1ementat1on of the Reservation System followed the 
second testing period. This testing period continued to use the 
manual schedule book as a backup, but more and more reliance was 
placed on the automated Reservation System. The results were very 
good and the system was considered operational at the Metropolitan 
campus. 

Chronologically, we set forth the following milestones: 



A stand-alone Reservation System Jan 88 

Access by all counselors jan 89 

Migration to other campuses Jan 90 

Multiple updaters on the system March 9^^ 

In small systems development, it is typically a surprisingly I rge 
leap to move from a stand-alone or single user application t^ m 
which is networked or nrovides for multiple access. The te Jcal 
tools provided on the smaller systems are not geared for ianii-user 
systems, and in general the data becomes much more vulnerable when 
"opening" up the system to multiple access. 

As mentioned, the counseling area was equipped with an Ethernet local 
area network which originally ran 3Com's Eth^rSeries network software 
(this is now rfevell Netware). The physical and logical network 
components mn in place to allow access from the counseling offices, 
but there remained the technical problem of modifying the application 
to support ..jltiple or concurrent usage. 

We proceeded cautiously in this inplementation. tte clearly separated 
the functional milestone of adding additional "queriers" to the system 
and the milestone of adding "updaters" or the ability for two users to 
concurrently change the data. We u, -stood that from a needs 
perspective, the counselors wanted the following from our system: 
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0 Inspect their schedules from their cm PC Morkstatlons 

0 Inspect a student's record or history with the office 

0 Inspect their peers' schedules and cornnltments 

for which all three of these needs precluded any changes to the 
database; thus, they needed only to read or quer7 the files as opposed 
to updating or changing the files. 

The developKnt environment, namely dBase ADL and a dBa^e compiler 
called Clipper (Nantucket Software), allows for multiple user 
capability. However, the lack of built-in or supplied data Integrity 
and access control features places a considerable burden on the local 
programming and application design work. 

We have, quite simply, moved slowly on this front because of a concern 
of losing reliability and simplicity In the system. It would be 
disastrous, at this point, to Introduce multiuser database problems to 
a system which has such an excellent track record of reliability. 

Instead, we have completed a query "module" or separate program which 
Is a subset of the full Reservation System* This module Insures no 
updating or changing of the system's datasets can be accomplished. 
This module Is accessed by multiple counselors from their workstations 
and gives each counselor the ability to Inspect or read all of the 
Reservation System's scheduling and student Information. 

We will migrate this current form of the application to the other 
campuses during this year. Our final milestone. Is the completion of 
multiple user appointment updating of the system. This would be most 
helpful In times of high student activity and would allow the system 
administrator the ability to change or alter information while the 
Reservation System Is In use. Additionally, It opens up enhancement 
questions such as counselors scheduling their own appointments and 
adding comnents or tracking Information to the student records file. 

IV. Summary ^ Recoomendatlons 

Readers knowledgable on technical matters regarding PC's, LANs, and 
networked applications might question the degree to which the 
developer's uinge caution and a conservative approach In developing 
these types of applications. There are certainly products and 
development tools which promise such things as true multiuser database 
management and Integrity controls In this environment. However, It 
has been our experience that cost, and a lack of prevalent technical 
expertise can mitigate their usefulness. 
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As £ ca«e stiKjy, the development of this Reservation System is likely 
very representative of efforts taking place across the country. These 
development efforts are quite entrepreneurial in nature and typically 
involve a key ''user" (i.e. our counseling director) and a sympathetic 
consultant in the computer or MIS center. We readily endorse this 
model, and observe the following advantages: 

0 The vision and enthusiasm for the project is very focused which 
enhances the likelihood of success and decreases the likelihood 
project »rin get sidetracked or continually redefined. 

0 The project is namwly defined, technically conservative, and 
can be delivered quickly. In this model human and technical 
resources are alt^ys at a premiun; this necessitates the 
project "team" utilize and stretch their available resources, 
and implement before the resources "dry-up." 

But, Me have the follcwing caveats as well: 

0 Alwaors search the market fo>^ in existing solution or one which 
can be customized to fit your needs. This can be a difficult 
"pill" for the designer and developer who are excited about 
applying their own solution. 

0 The project must fit into some overall strategy or context. 
The end result should add value to larger or more conspicuous 
development or IS initiatives, and should fit into these 
efforts. 

At CCC, this Reservation System development has been an 
entrepreneurial enterprise. The design, implementation, and expansion 
of the system has taken place with minimal resource impact and has 
been largely a prod tct of one key user's innovation add hard work. 
However, the .^vstem does have an excellent fit with larger development 
strttegies. 

The counseling and advising areas, in addition to their networkina and 
telecommunications capabilities, will shortly benefit from the 
delivery of a Degree Audit system which is built around their PC 
workstations and micro to mainframe communications and interfacing. 
This Advising ind Graduation Information System (AGIS) fits very well 
with the Reservation System. Each serves a separate purpose, but the 
access, look and feel, and training and orientation of its users go 
hand in hand. 

In all of this technical detail it is important to remember that the 
College's technology motivation is not about computers and hardware 
and wires. Its about quality and effectiveness. The opportunity to 
work smarter i» the College offices, and to inprove the qualit> of 
instructional programs, and most importantly to enrich the lives of 
each and every student who walks through our doors. In its own smV 
wjor, we feel this system contributes admirably towards this goal. 
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CASE TOOLS for the 90' s: DELIVERANCE OR EXTRA BURDEN 
Dr. Paul J. Plourde 
Pent ley College 

Computer Information Systems Department 
Waltham, Massachusetts 



This paper examines the viability of CASE (COMPUTER AIDED 
SOFTWARi; ENGINEERING) as a replacement for the design and 
development strategies that have been employed in the past: 
namely^ manual design and programming of application systems. 

The primary focus will be on developing evaluation questions 
and assessing whether or not industry reports support the notion 
that CASE tools boost productivity and reliability of systems 
that are developed using these tools. 

Consideration will be given to the questions of the 
necessity for the integration of CASE ijols with other tools such 
as data base management systems, 4GL's, as well as, other CASE 
♦crols. 



During the early 19708, computer centers and systems development 
departments were abuzz with a new technology In the form of data 
base management systems (DBTS) . Systems analysts and programmers 
were charged with determining the capabilities of the 
commercially available DBMS' and ascertaining what, if anything, 
such systems could do for their organizations. 

The results of these investigations are history and many 
organizations adopted the use of these systems to provide more 
timely and integrated information for their users. However, 
the impact on the systems development organization was not as 
smooth as this scenario might imply. In the first place, there 
is a difference between acquiring a tool and altering the methods 
(techniques) used to develop systems. In the case of DBMS, 
acquiring a DBMS package di<l not insure that it would be utilized 
for something other than a replacement for the current disk 
accent ing technique whether it be random or some form of indexed 
sequential. It was quite another matter to have analysts think 
in terms of an integrated data base for the organization and to 
develop systems with this concept in mind rather than focusing on 
the single system appxoach to development. 

As we enter a new decacf.e, we are faced with a new buzzword (CASE) 
which promises to revolutionize systems development and have i n 
impact that could be more profound than that which we experienced 
with data base management systems. Even with this promise, the 
potential problems of integrating the use of CASE tools in an 
information systems organization are as foreboding, if not more 
so, than was the case with incorporating a data base management 
system (and the associated data base philosophy) into the tool- 
set used by systems developers. 

The purpose of this paper is explore this new technology, 
indicate how it evolv i, as well as, describe its current status, 
and identify some evaluation criteria and problems of integrating 
this new technology into an existing systems development 
organization. 

It is difficult to cite an exact definition for CASE (Computer 
Assisted Software Engineering) but there is a common thread to 
many of the definitions that have been advanced. There seams Lc 
be a consensus that CASE deals with automating (applying the 
computer to) the systems development tasks and that the goal is 
to increase the quality of the software produced and improve 
control over the process of developing systems. From this 
definition, it is conceivable that a broad variety of existing 
tools could fall under the rubric of CASE tools including: 

1) analysis and design tools (front-end or upper case tools 
including graphics, data repositories and process 
definition systems, 
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2) programming support tools (back-end or lower case tools) 
including code generators, screen painters, optimizers, 
editors, as well as, reverse engineering tools, and 

3) project management tools. 



A more specific definition of the components of CASE is offered 
in the many reports issued by James Martin on this subject and 
he suggests that there are five components of CASE: 

"1. front-end design and specification graphics support, 

which at least relieves the analyst of the manual chores 
related to drawing and redrawing diagrams as the design 
evolves ; 

2. design analysis, which at least tracks and reports basic 
design flaws such as design pieces that are not related 

to any other piece of the graphic presentation. Some of 

the rule-dr>'en tools now emerging can also detect other 
inconsistencies ; 

3, code generation, providing automatic translation of the 
specifications developed by the earlier components into 

source or machine code; 

4. a "repository," "encyclopedia" or "metadictionary, " 
which holds comprehensive entity models or views of the 
structure of the organization usinq the CASE facilities; 
and 

5, "absolutely essential ro the effective use of other 
elements" is a PC or similar commonly-used processor, 

which in addition to being a famiJ'ar, non-threatening 
and easily accessible piece of eqt .pment, is (under 
CASE> provided with "very good interfaces including 
windows and aenus and color." (Leavitt, pp. 50-51) 

With this admittedly sketchy understanding of what a CASE tool 
can accomplish, let us consider how we arrived at this juncture. 
In what must be considered a rapid succession of events, we have 
proceeded from developing computerized solutions to business 
problems by generating machine language code, to symbolic code, 
to compiler languages, to fourth generation languages and to the 
present state of CASE which is a spocif ication-driven language 
that may or may not be tied to an automated code generation 
facility. 
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The infiltration of CASE into systems organizations is 
reasonably woll documented but studies of their effectiveness 
in producing quality systems and/or reducing the backlog in 
systems are in the early stages of being undertaken and the 
rosults have just begun to appear in the last two years. 
Since tev integrated CASE tools such as TI's Integrated 
Engineering Facility are on the market, statistics on utilization 
of CASE tools and their various derivations can be misleading. 
The norm for a company seems vo be to utilize either an upper or 
lower case tool in a stand-alone fashion or they use an upper* 
case tool from one company coupled with a lower case tool from 
another company. 

Based on the number of users of CASE tools on mainframes, one 
would not necessarily assume that there is and will continue to 
be a tremendous growth curve in this industry. As Myers noted 
(reporting on a study conducted by Computer Intelligence Corp.), 
"only 2% of U.S. mainframes have one (a code generator) 
installed** (Myers p. 49). However, such figures are quite 
deceiving since much of the current development in the use of 
CASE tools is with front-end tools or is PC based. Index 
Technology's Excelerator, which had 23% of the CASE market share 
in 1987, as reported by the Computer Systems News, reported in 
late 1988 that it had shipped the 10,000th copy. 

In a compilation of eighty-five (85) CASE software products 
included in a Karch 1989 Computerworld article by Santosus 
(pp. 77-86), thirty-five (35) were PC based and another twenty-one 
(21) were workstation based (SUN, APPOLLO, VAXSTATION etc.). 
Only thirty-two (32) products worked solely with mainframes to 
the inclusion ol PC's and workstations. The fact that many of 
the PC and workstation products a} so worked on the mainframe or 
had mainframe interfaces suggests that as one moves towards an 
integration of upper-case tools and lower-case tools the 
mainframe is more likely to be involved. 

WHY CASE? 

It is a well documented fact that in most information systems 
organizations have backlogs of requests to develop new systems 
or maintain existing systems. Added to this is the geometric 
rise in the number of computers and the declining number of 
graduates frcm computer science and computer information systems 
programs. The result of these factors as noted by McFadden and 
Discenza is that 

**A crisis in software development plagues American business 
today.. In total, the number of new applications ... in the 
backlog undoubtedly exceeds the number of all existing 
applications. . .and the (IS) organization cannot respond to 
the need for new systems." (McFadden and Discenza p. 68) 
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The net result of more computers, fewer trained IS people, 
and a huge backlog of requests for new systems and changes Is 
that we cannot hope to satisfy our organization's systems needs 
with the use of traditional tools. Some observers suggest that 
Increased user Involvement with systems development Is the 
solution while others such as HcFadden and Dlscenza argue that 
the solution lies with use of fourth generation languages. An 
Increasing chorus can be heard In favor of Increasing product- 
ivity through the use of CASE tools as a complement to user 
development end using 4GL's and other user-oriented tools. 

It Is not surprising that accurately measuring productivity is 
and will continue to be a major focus in determining whether 
there is a payback in using CASE tools. Barry Boehm, who 
developed what some consider to be a landmark survey of 
productivity tools in the 1970' s, has done some tests and reports 
on the perceived payback of CASE that 

•'when developers were given their own workstations and a 
set of tools that covered the entire life-cycle, not just 
programming, a productivity gain of 50% was found." 

(Knight p. 56) 

Similarly, Necco, Tsai and Holgeson, in a study conducted in 1989 
to determine if industry has aggressively tried to implement this 
new tool, found that 

"only twenty-four percent (24) of the responding companies 
indicated that they were utilizing a CASE tool... and a 
majority (60%) acknowledged that the CASE tool 
significantly Improved the quality of the product, but only 
47% indicated a significant Improvement in productivity. "p, 8 

Necco and his colleagues furtner report that 

"An analysis of the factors that influenced these 
Improvements reveals that more than half of the respondents 
noted a significant Improvement in the communication 
between the analyst and the systems users. Sixty peicent, 
however, indicated that the tools did not Improve project 
control, and would not make future malr Penance changes 
easier." pp. 9-10. 

In a study of 3,000 active users of front-end CASE tools in the 
U.S., the Barton Group found that 

••Users report that exceptionally strong and widespread gains 
are made in documentation... 

A very large group reports respectable but not extreme 
Improvements in... the quality of system? design.. 
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Many users report strong improvements in ...the ability to 
meet business requirements. • t 

Responses indicate a widespread, mid-level improvement in 
communication, as the tools force standardized outpucs 
and documentation s^.ts. 

Host projects experience moderate improvement. . in 
productivity. .more time is needed to improve ..productivity 

Most people experience minor improvements in.. project 
schedules. The learning curve is greater than expected, but 
this is offset by improved documentation and communication." 

(Merlyn and Boone p. 66) 

Regardless of the preliminary results on the success of CASE, 
supporters contend that benefits will be derived. Charles Martin 
in a vendor sponsored meeting of Excelerator users suggested 
that productivity improvements can come from four areas: 



"Methodology training and enforcement— 
The CASE tool helps train junior analysts in advanced 
techniques and enforces consistent usage throughout 
the organization. 

Support for systems analvsis diagrams— 
Interactive graphic editors help analysts to develop the 
kinds of process, data base, and program structure diagrams 
which have proven to be the most effective way to 
communicate concepts behind the reqpiirements and design. 

Single entry specification bookkeeping — 
Operating from an Information Resource Dictionary System, 
redundant specification documentation (viewing ihe specif- 
ications in different ways) can be prepared from non- 
redundant dictionary representations. 

Reminds and consistency checks — 

Complex inter-related bookkeeping chores are eased by CASE 
tool reminders of cdditional information needed to complete 
specifications and automated conslL^tency checks." p. 56. 



CASE EVALUATION CRITERIA 

Until we encountered the introduction of DBMS in the early 
1970's, many of us were unfamiliar with solxware RFP's and 
such exorcises were limited to the acquisition of lardware. 
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Since that time, software RFP's have become more common for 
all but the smallest computer Installation. Many among us have 
drafted RFP's for application software, LAN software, screen 
painters, 4GL's and other software. Thus, It Is not surprising 
that the first admonition Is to study the company, Its direction 
and the product direction. Just as there were many start-up 
companies In the DBMS field that didn't survive the maturing 
of the technology; such may be the case with vendors of CASE 
tools and some suggest that this phenomena Is already repeating 
Itself In the area of CASE tools. As Grochow of American 
Management Systems notes: 

"there were 50 code or application generator producers In 
1982 when first became Involved In the technology. 
Today,... of those 50, 10 are still around but there are 40 
more. It's a volatile market-** (Myers p. 68) 

A number of articles suggest evaluation criteria and checklists 
for Identifying which CASE tool or set of CASE tools might best 
suit the needs of your organization. While most articles include 
a checklist of sorts, the articles by Aranow, Gibson, 
Santosus, Troy and Zucconl focus in particular on this issue. 

Beyond vendor issues, some of the major questions are listed 
below with each of these questions having numerous sub-questions. 

EVALUATION QUESTIONS 

Does the product SUPPORT THE ENTIRE LIFE CYCLE and is this 
provided by a set of products as opposed to one product? 
If a number of products are used, how well are they 
Integrated? 

Is SUPPORT provided foi the MAJOR DEVELOPMENT METHODOLOGIES 
such as Demarco, Gane and Sarson, Yourdon etc. ? 

GRAPHICS CAPABILITY (DFD's, Flows, Action Diags, Models 

Does it SUPPORT lOGICAI OATA BASE MODELLING? 

Does it SUPPORT A CENTRAL REPOSITORY? 

What PROTOTYPING CAPABILITY is provided? Is this an 
Industry capability or is it product specific? 

What PROJECT MANAGEMENT TOOLS ar^ provided and supported? 
Are these industry' compatible or unique? 

Is t^ils a MAINFFAME and/or PC BASED system? 
If both, what Interfaces exist? 
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Is there provision for MULTIPLE USER ACCESS? 

Does this Include support for major LANS? 

Is It INTEGRATED WITH MAINFRAME DBMS & DATA COMMUNICATIONS 
with LANGUAGES, DSS, 4GL'S & other CASE TOOLS 

Is there CHECKING OF SPECS FOR COMPLETENESS & CONSISTENCY 

Does an EXPERT SYSTEM EXIST TO CHECK QUALITY & ACCURACY OF 
DESIGN? 

Does the system SUPPORT AN OPEN ARCHITECTURE PHILOSOPHY? 
What are the HUMAN INTERFACES and TRAINING TOOLS? 



POSSIBILITIES FOR SUCCESS 

Having evaluated and selected* a CASE toolset, what are the 
possibilities of successful use, are there any strategies that 
will help and what problems aru likely to be encountered and can 
they be avoided? Merlyn and Boone suggest that "success Is not 
an automatic outcome of CASE** (p*68) and they cite a list 
of suggestions compiled as a result of the Barton study (noted 
above) about what organizations should do to derive the maximum 
benefit from the use of CASE products. 

The suggestions from the Barton Group study are as follows: 

"Establish a means for measuring results that addresses both 
sho' t- and log-term costs and benefits. 

Keep expectations lealistic. Look for short-term 
improvements in communication and the quality of 
deliverables, but do not expect major Improvements • 
for at least three years. 

Move slowly and carefully. organizational changes are 
required therefore move Incrementally 

Scout the territory. Companies that understand the methods 
first nave a better chance of success. 

Test extensively. • .conduct at least four pilot projects 
Forgive test errors. Expect to make mistakes. • 
Allow for postpurchase expenses. 
Splurge on training. . .and. . supply coaching. 
Focus on use and support ..and., encourage full use. 
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Address ozganlzatlonal issues. 
Make Improvement a strategic goal. 

Involve the project manager." (Merlyn & Boone pp. 68-69) 

Burkhard also suggests that certain guidelines be followed to 
insure success and that "like all correct development cycles, the 
implementation plan must be committed to a structured 
methodology." (p. 21) Danziger and Haynes -^cho these findings. 
The adoption of a new technology is often accompanied with 
problems and CASE implementation is not an exception. There 
aren't any standards and there are scores of vendors marketing 
all sorts of products under the aegis of being a CASE tool. 
As was the case with local area networks the major hardware 
manufacturers have stayed out of the fray until recently when IBM 
acquired a percentage of Index Technology while at the ^ame time 
pushing forth its own AD/Cycle Information Model (see Hazzah 
Dec. 89 for a discussion of AD/Cycle). 

A significant problem which again parallels the data base 
experience is that CASE technology is ahead of the CASE 
techniques that people employ. This is partly due to inexperience 
but it is also due to analysts not understanding the methodology 
or technique that the company may be implementing at the same 
time that the Case tool is being adopted. Thus^ one should not 
o^ <^rlook the learning overhead for both the CASE technology and 
the various methodologies sc.ch as Gane & Sarson that the 
installation might be installing. 

The human factor plays an important role here as it ^id when 
structured walkthroughs were first introduced 15 years age. 
People are fearful of their jobs but, even if they overjook this 
factor, they may not trust the tools. Beyond this the tool and 
the learning curve associated with its use, can be used to cover 
up unsound design (s). 

The interface of the various CASE tools both with other CASE 
tools and with other software packages that a given organization 
might use or plan on using such as a DBMS or 4GL is of vital 
concern as one contemplates the role of CASE in an organization. 
The articles by Myers and Weitz and the articles referenced 
earlier that develop evaluation criteria address these issues. 

The next steps for CASE technology seem to be weJl defined: 
there will undoubtedly be a vendor shakeout, the major players 
will be identified, de-facto standards will be set, an Increasing 
number of interfaces will be built between upper, mid and lower 
case tools, as well as, with other software. From a capability 
perspective, a new generation of knowledge-based expert systems 
will vault CASE into the hoped for productivity gains. 
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